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[57] ABSTRACT 

The present invention provides methods for opecaiing.a 
local terminal which includes a programmable com- 
rputer *o that the terminal executes a pre-aiTanged applir 
^^cation program. More specifically; the present inven- 
tion provides methods for operating a local terminal 
according to a pre-arranged application program which 
is created on a remote computer, then communicated by 
a conuntmicadon channel to the local terminal where it 
is stored for execution. 

18 Claims, 65 Dnwing Figures 
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What b clainwd is: 

1. In a method for operating a local terminal whkh 
includes a local computer system compristng a central 
p rocea ao r amt» a read only memory co^pted to said 
central pr o ccaaof unit, a random access memory cou- 
pled to said central p r oce s sor unit, and a communica- 
tion channel coupled to said central pr o ccsao r unit for 
conmiunicating with a remote computer system, the 
steps<rf^^ . 

^^loftMafaa^ a set of general purpoae operation 
ttkttniei to'^be caecuted by said local compuier 
sj^stem, each of said genera] purpose operation 
routines comprising a set jaf instmctioos fior eaceco- 
tion hy said central processor unit in a prearranged 
m a nnf r to accop|rfish a upccifi c task; 

K sjbnmgf said fet o^^ purpoae operation rou- 

tmes m said read only memory 

c. defining a set of commands where each command 
of said set of ccmunands is associated with a specific 
general purpoae operation routine and indttdmg at 
least an op e ra t i on code of a plurality of operatioo 
codes relating said c omman d to said specific gen- 
eral purpose o p er a t ioo routine, ea^ of said com- 
mands having an associated r"tPTT?**wf code l en g t h 
whicfa is either equal to or, in most cases, snbatan- 
tiaDy less than the cotte lei^rtb of said ^Ncific gen- 
eral purpose operatioo routine; 

d. fttabllshing at said remote computer system at least 
one ^iplicatioo program m o dule cowipnsmg a pre- 
arranged sequence of said commands; 

e. comm w n i ratm g said application p ro gram module 
from said remote c o m p u t er system to said local 
computer system via said cjommuniralion rhannffl, 
inchiding the step of storing for each of said set of 
commands said operatioo code associated with said 
prearranged sequence of commands in said random 
acccM wtsDoryi and 

L cstablishmg In said local computer system a pro- 
gram cxecutiOQ routine for enahltng said central 
processor unit to eaw cu te said apf^icatioo program 
module by riqielilivdy peifuiuiing the stqn 

(1) reading said associated operation code stored in 
said random acceii memory, 

(2) arrrrwig a specific general purpose operation 
routine associated with said read operatioB code; 
and 

(3) executing said specific general ptu p ose oper^ 
tion routine 

X In a medmd for operating a local terminal which 
inchides a local comp ute r system gnmpriaiftj ^ central 
pr o cess or unit, a read only memory coupled to said 
central p roces sor unit, a random access memory cou- 
pled to said central proce ss or unit, and a communica- 
tion channfl co upled to said central processor onit for 
commumratmg with a remote computer system, the 
steps of: 

a. defimng a set of different specific tasks to be carried 
out by said local computer systen^ 

bi estaUishing a act of general purpose operatioo 
routines to be e x ecute d by said local computer 
system, each comprising a set of instructions for 
ciecntion by said central processor unit In a prear- 
ranged manner to accomplish one of aid specific 
tasks; 

c storing said set of general purpose operation rou- 
tines in said read only memory; 

d. defining a set erf* commands where each command 
of said set of commands is associated with a specific 
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one of said general purpose operation routines and 
including at least an operation code relating said 
command to said specific general purpose opera- 
tion routine, each of said commands having an 
associated command code length which is either 
equal to or, in most cases, substantially less than the 
code length of said associated general purpose 
ope rati on routine; 

e. establishing at sakl remote cmnpnter system at least 
one application program module cfflnpnsing a pre- 
arranged sequence of said commands defining a 
desired fonctional feature for said local terminal; 

f. c omm u iu cautig said application program module 
from sakl remote computer system to said local 
coo^mter system via sakl oommunicatkm channel, 
including the step of storing for eadi of sakl set of 
commands said operation code associated with said 
prearranged sequence of commands in said random 
access memory; and 

g. estaUishing in said local computer system a pro- 
gram execution routine for enabling said central 
processor unit to execute said application program 
module by repetitively performing the steps of: 

(1) reading said as so ci a ted operatioo code stored in 
said random access memory; 

(2) accessing a specific general purpose operation 
routiM as so ciated with sakl associated operation 
code; and 

(3) executing sakl qtedfic general purpose opera- 
tioo routiiie. 

3l In a method for operatmg a local terminal to per- 
form a set of predefined Amddons, said local terminal 
inrhirttng a local computer system co mp r isi ng a central 
proce ss or unit, a read only memory coupled to said 
central processor unit, a random access memory cou- 
pled to said central processor unit, and a communica- 
tion channd coupled to said central processor unit for 
oommunicatmg with a remote computer system, and 
mput means for if1f<ning one of sakl predefined fonc- 
tiODS, the steps ofr 

a. fstahKshtng a set (tf general purposes operation 
routines to be executed by sakl local computer 
system, each of sakl general purpose operation 
routines comprising a set of mstmctions for execu- 
tk» by said central processor unit in a prearranged 
manner to accomplish a specific task; 

b, storing said set of general purpose operation rou- 
tines in said read only memory; 

c defining a set of conimands where each command 
ofsaidsctofcommandf is associated with a ^)ccific 
general purpose operation routine and inchiding at 
least an operation code relating said commands to 
sakl specific general purpose operation routinev 
each of sakl commands hsiving an a itocisted com- 
mand code length wh^ b either to or, in most 
cases, substantially fass than the code length of saki 
specific general purpose operation routine; 

d. es^blishmg at sakl remote computer system a plu- 
rality of application programs, och of sakl an>tica- 
tion programs comprising a different set of applica- 
ticm p rogr am modules which together dd5ne a 
different set c€ predefined fonctkms for a kxal 
terminal to perform, each of sakl application pro- 
gram modules comprising a prearranged teqnence 
of said set of commands to provide one of said 
predefined frmctions; 

& c ommnni c at i ng a preselected application program 
from said remote computer system to said local 
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said | w ogfi n data structure amy established in step 
h. ittdodes a first slot which comprbes a main slot 
into which data stroctores for a main appKcaskni 
prc^ram module are loacted; 

said DONE routine indudcs i nstruc tions for loading 
an bit locations in said ACTIVE PROGRAM 
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bitmap with said second bit vahie tndicafing the 
absence of an active application pi o gram module 
except those bit locations cofresponrting to bit 
loca t iotis in said BACKGROUND bitmap having 
a fint bh value indicating a background attribute 
for said active applwatioo program module; and 
said step a. includes the step of: 
(4) establishing as another one of said general pur- 
pose operation routines a START BACK- 
GROUND rootxnc compiising instructtons for 
calling for execution of a specified application 
p i o gram module in a specified slot number with 
background attnbnte» including instructions to 
load the bit location in said ACTIVE PRO- 20 
GRAM bitmap with a first bit vahie mdicating 
an active apfrfication program modute in the 
spedlied slot number and to load the bit location 
m said BACKGROUND bitmap with a first bit 
value indicating a background attribute for said 25 
active api^ication piugiam module. 
8. The method of daim 4^ wherein 
said local terminal includes at least one other mpnt 
device cou|rfed to said central procesaof unit in 
addi t ion to said communicatioo channel; ^ 
said s dic du le r data suuctui e established in step L 
fhrther compris es a plurality of REALTIME 
PROGRAM data dements each associated with 
one of said iTOgiam data structures in said program 
data array and storing in a specific tnt locadon one 
of two data values indicating whether or not an 
active apfdicatioo program module In a corr^ 
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spooding slot of said piogiam data structure array 
is waiting for input from one of said communica- 
tioa rhannfl or said other input device; 
said step a. hidudes the steps of: 

(3) establishing a plurality of said general purpose 
op eratio n routines rach i de machine instmctians 
tttibzmg inputs fro^n said oomfTHrntcatio'U c^ban— 
nd or said other mpot device; and 

(4) fstahttthing at least one gepcnl purpose opera* 
tion routine in^iich inchxles izatructions for load- 
ing the bit location m said REALTIME niO- 
GRAM data dement corrcayondmg to the appli- 
caiioo program module in whidi said general 
purpose ope i aii oi i r oii i i nc is executed with a data 
value inriir a ting that said appBcatiop p rogr am 
mo du l e is waiting for mpat from said ctmmuni- 
caticp channel or said other mput device; 

and said scheduling prog r am routine established in 
stq> j. enables said central p ro cessor unit to carry 
out the steps of: 

(1) deteiiuining wh ether any inimt from said com- 
munication chaimri or said other input device is 
waiting to be read; 

(2) when input b not waiting to be read, perfbnn- 
ing said ^ep of srhrdnKng the yqnmtial execu- 
tion of active application program modules one 
at a time based sddy on the data values stored in 
said ACTIVE PROGRAM dau dements in said 
a d iedn l e data sti uctur ea, said ne cntkm of each 
active application pn^ram module continuing 
until said WATT routine is executed or untO said 
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program module has completed execution; 

(3) w^en input is waiting to be read, performing the 
steps of: 

(a) reading an input from said communication 
channd or said input device; and 

(b) KihcduKng the execution of only said active 
application program modules having a dau 
value in a c ui f op onding REALTIME PRO- 
GRAM data deooent which indicates that said 
application pi ogr am module is waiting for 
input until »id read input is used by one of 
sdd ap^ication program modules and then 
returning to said step (I) above* 

9. The method of claim 8, whmin 

said data structure format defhied in step g. includes 
a phuality of DEVICE data demenu eadi associ- 
ated with said communication channd or said 
other input device and storing cme of a first or a 
secood data vdue indicating whether or not the 
^edfied apj^ication program module needs input 
from said communication channd or said other 
input device; 

said step a. includes the st^ of: 

(4) establishittg as <me of said general purpose oper- 
ation routines a NEED INPUT routine which 
indules instructiotts for loading a specified set of 
said DEVICE data elements in an assoriatrri 
application program module with said first data 
value indicatmg that said appiicatiott program 
module needs mpitt firom said communication 
channd or said other input device; 

and said step (b) indudes the steps of: 

scheduling for execution one at a time in sequence 
each of said application jmgram modules having 
a first data vdue in the corre^nding REAL- 
TIME PROGRAM dau des^nt; 

examining the DEVICE data dement corre spon d- 
ing to the source of said input in said ^ogram 
data structure aMociatfid with eadi scheduled 
applicatwo prt^ram module to determme 
whether or not said scheduled application pro- 
grsm module needs said read input; 

if said DEVICE data dement indicates that said 
read mpnt is nc cded» proceedmg to exe cu te said 
sch ed u led applicatmn program module; and 

if said DEVICE data element indicatCT that said 
read input is not needed, returning to step above 
to schedule the next a ppropriate a|^>lication pro- 



10. The method of claim L wherein 
said step a. indudes the steps of: 

(1) estaHishing a subset of parameter dependent 
generd purpose oper ati on routines, each of said 
parameter dependent generd purpose operation 
routin e s tndnding instructiotts that use a prede- 
fined set of parameters, tndnriing a sut»et of 
parameters that arc r eq uir e d to be supplied by an 
awociatrrf one of said s^ of commands, each of 
said parameters c omp ri sin g one or both of a 
paramftrr address or a parameter vdue; and 

(2) establishing for each of said parameter depen- 
dent generd purpose operation routines a set of 
parsing rontittes for determining the address and 
value of eac^ parameter in said subsa of parame- 
ters; 

said step c. indudcs the step of: 
de&nng a subset of parameter dependent com- 



675 



4,724,521 



676 



IS 



ma&ds, escb of said psmncter dependent com- 
mands being assodsted widi one said panunc- 
ter dependent general purpose operation rou- 
tines and inchiding both a definisd openticm 
code and an ordered list of paramrfw types cor- 
reqxsDding to said sobsel of parameters required 
to be supplied by said command; 

said step d. includes the step of: 
fStaWtshmg for each use of said parameirr depen* 
dent commands in said application program 
module an ordered Hst of actual parameter speci- 
fiers corresponding to said ordered list of param- 
eter types; 

said step e. inchides the step of: 
stofing, in assoctatioii with eadi of said set <tf com- 
mands of said operation code associated with a 
parafloeter dependent oom^Qandf sud ordered hst 

of •^H^l j^m^mr «p^fi«>r«; 

said Step f. (3) inchxles first performing with respect 
to each of said actual pa ramct fr spcci fie ra the steps ^ 

of: 

(a) readmg said paramrtrr spedfieis; 

(b) executing an associated one of said parsing 
routines to obtain the address and value of said 
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(c) Storing said paramrtrr address and value; 

followed by the step of executing sail 
op erat ion routine using one or both of said parame- 
ter address and value for eadi of said parameters. 

11. The method of daim 1 where said general pur- 
pose (^)eratioo roottnes have a specification of parame- 
ters» ftmher comprisittg the steps of: 

g-11. defining a set data types that may be used to 
satisiy said specification of parametera utilized in 
said general purpose operation routines; 

h-U. defining a set of p a r a meter types that may be 
utilized in said general purpose operation routiDes» 
jndnding defining for och of said parameter types 
an aiforiatfd subset of said data types which may 
be used to satisfy said parameter tjrpes and a cofi^ 
spooding set of different data type values which 
may be utilized to specify said data types in said 
s ubset ; one group of said parameter type% Ivexng 
noD-varyittg paramete r types havmg an associated 
subset of only one of said data types, and another 
group of said parameter types being varying pe- 
nmeter types having an associated subset (tf a 1^ 
rahty of said data types; 

k11. establishing a set <^ data type parsnig routines 
each co mprisin g a set of instructioas for obtaining 
at least the address and value of a parameter satis- 
fied by an associated one of said dau types; 

J*ll* estaWishmg a set of paisng control routines 
each associated ^vtth ^^t^ of said parameter types 
and comp ri sin g in s tiu ctions for sdect a M y execut- 
ing one oi a sobaet of said data type parsing rou- 
tines corresponding to said associated subset of said 
data types, said sid»et having a single member 
when a parsing control rouiiiie is awocwted with 
one of said noo-varying parameter types; 

k-l 1. establishing a set of imociatrd comrnand pars- 
ing modules where each associated roimnami pars- 
ing module is auociatrd with at least one of said 
general purpose operation iomu ic s and comp i isiM g 
instnicti(ms for calling the execution of a std»ct of 
said parsing control routines in pre<staUisbed 
ordered seciuence; said subset being a null subset in 
dbe case of each of said general purpose ope ra tion 



55 



60 



65 



routines that do not utilize any of said parameter 

1-11. storing each of said data type parsing routines, 
said parsing control routines, and said command 
parsing modules in said read only memory; 
and wherein said step a. includes the steps of: 

(1) establishing for each of said general purpose oper- 
atioo footiiies an operation loutiiie which utilizes 
one or both of the address and value of a subset of 
said parameter types, said subset being null in the 
case of each operaboo routme that does not require 
any command specified para ip^^e rs; 

(2) in corpo ra ting into each of said general purpose 
operation routines a specific command parsing 
mo dul e; and 

said step b. in^iules the step of: 
stOTing said c^eri^ion roudne for each of said general 
purpose operation routines m prearranged rdation 
to said Sf i fci fiii command parsing module; 

said step c. inchides the step of: 
definiog for each of said commands a subset of said 
paranieter types m an ordered list corresponding to 
one of said ordered sequences, said subset being a 
nuD subset when each co mmand associated with an 
operation routine has an atwdated null subset of 



typo; 

said step d. inchides the st^ of: 
establishing for each use of each of said commands in 
said appiicattott program module a subset of actual 
parameter type specifiera which are in the form of 
an ordered list and a set of data type dau dements 
^^nch are in the form of an ordered sequence of 
data eirments c orr e sp onding to varying parameter 
types in said or d ered list of actual parameter type 
specifiers, eadi of said data type data dements 
having a value designating which of said data types 
said actual parameter type specifiers are associated 
with; 

said step e. inchides the step of: 
storing said ordered list and said ordered sequence 
established for each usage of each cOTunaiid in said 
random a cc e s s memory in predeterniined relation 
to said opcnSioo code; 

said step t P) includes die steps of: 

(a) first executing said associated command parsmg 
module, including executing asso ci a ted parsing 
control roatmes and data type parsing routines 
based on said or de re d sequence to obtain the ad- 
dress and value of each parameter required by said 
operation routine; and 

(b) storing the address and value of each of said pa- 
rameters as diey are obcamed through execution of 
said data type paising rowiines in luearranged loca- 
tions in said random access memory and 

(c) then Mfcntmg said operation routine associated 
with one of said general purpose operation routine 
ntiliTing one or both of said address and vahM of 
each of said parametcts. 

IX The method of daim 11* wherein said data type 
parsing routines* said parsing control routines, said 
command parsing modules, and said operation routines 
are stored in separate areas of said read only memory 
with each of said r o utin e s having a predetermined start- 
ing address 
said step c. ctmiprises the steps of: 
(1) assigning to each of said general purpose opera- 
tion routines operation codes c ompr i s ing a nu- 
merical vahie m sequential nmnerical orden and 
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(2) establiafaing an oper at ion code jump table com- 
prising a sequential li^g of a lint and a second 
address element for each of said operation codes 
in the same numcrwal order as said assigned 
<»der of operation code valneSp the first address ^ 
element eft i w ip ri ain g the starting address an 
swft^ntfd of said cftnunaiHt p^r^ftg modules 
and the second address dement comprising the 
starting address of an asaodated one of said oper- 
ation lotttines; 
said step f. (2) comprises looking up in said operation 
code jump table the first address element at the 
pos it i on in said jump table correspon d in g to said 
numerical value of said operation code; and 
ssid step f. (3) (a) comprises eiecntittg the associated 
OTC c€ said command parsing modules located at 
said first address element looked up in said opera- 
tion code jump taUe; and 
said stqi f (3) (c) comprises execntittg the one ci said 
operation rcmtines located at said second address ^ 
element Allowing said first address element. 
xy Tht method of daim IX wherein a plurality <^ 
said general purpose ^leration routines have a set of 
ss so ci a ted parMneten co mpr i sin g a null set; one of said ^ 
command parsing modules c omp ri ses a null command 
parsiiig module which calls a nuO set of parsing control 
loiitiiict and itturiis to carry out step f. (3) (c)u 

14. The system of daim 1, vdiercin said step b. com- 
prises storing eadi of said g»eral purpose operation 
r opt ii ie s at a prearranged location within said read only 
memory having an associated startmg memory address; 

said step c. comprises the steps of: 

(1) assignmg to each of sakS general purpose opera- 
tion routines an operation code comprising a ^ 
numerical vahK in sequential numerical order; 
and 

(2) establishing an operation code jump table com- 
prising a sequcBtial listing of said starting 

memory address fior each of said o p er ation codes; and 
wherein said step f-(2) comprise s kwldng up in said 
o p erat io n code jump taUe the staitmg memory 
address of said associated senersl purpose opera* 
tion rootkie at the listing in sakl jump t able oofTe- 
spoodmg to said numerical value of said opers t iop ^ 
code and said step f.(3) comprises the step of se- 
quentially executing the instructions stored in said 
read only memory beginning at said startmg mem- 
ory addresSb 

15. The system of daim 1, further couipiising the step 
of: * 

g-15. defining an operatiop code system comprising a 
l^urality of opcode sets and a plurality of COTTC* 
ywufaig Opco des within eadi of said sets* such 
that each <ycrat>on code comprises an opcod e set 
^^signatum and an opcode dcssguabon; 
b-15. defhtmg an ob)ect code command syntax com- 
prisinig at least one data element having a set of 
possible values each designating one of said cqicode 
sets and at least a second data clement having a set 
of posnUe vahies each designating one of said 
operatioo code^ 
and wherein said step c. includes the steps of: 

(1) assigning each of said commands to a specific one 

of sakl opcode sets and assigning to each of said ^ 
rofnmtnrts in each opcode set a different opco de in 
sequential numerical order; 

(2) establishing a set of associated opcode jump tables 
each oQirespoiidtng to one of said opcode sets and 



co mpfisih g a sequential listing of operation routine 
pointers each comprising starting memory sd- 
dresses for the general purpose operation routines 
assoriiffri with the commands assigned to said 
corrcspondmg opcodes; 

(3) storing said set of opcode jump tables in said read 
only memory at prearranged starting addresses for 
eachc^saki taUes in said set; 

(4) establishing an opset pointer table comprising a 
sequential liAmg of said starting memory addresses 
for sakl associated opcode jump tables; and 

(5) storing sakl opset pointer table in sakl read only 
memory at a prearranged starting address; 

said step e. indudes the step of: 
storing said one dau element and sakl second data 
element in assnrialrti locations in said random ac- 
cess memory; 

sakl step t includes establishing a command execution 
data stf u ct m e including an opset data structure element 
and an opcode data structure element; said step f.(l) 
indudca the stq» of: 

(a) reading said one data element and storing the read 
vahie m a opset dau structure dement; and 

(b) reading said second data element and storing the 
read value in said opcode dau structure element; 

and said stq> fl(2) innludffs the stqn of: 

(a) calculating the pointer address of an opset pointer 
firom said starting memory addresses of said opset 
pointer table and said value stored in said opset 
dau structure element; 

(b) reading the value stored at said pointer address; 

(c) ralmlating the Ofpcodc pomter address of sakl 
opcode pointer from said read value and said value 
stored m said opcode dau structure densent; and 

(d) readmg the value stored at sakl opcode pointer 

and sakl step t(3l) comprises the stq> ci: 
executmg the general purpose operation routines 
stored in read <»ly memory at the addresses corre- 
sponding to the read value at said pointer address. 
16. The mettod of daim 1 u^ierein said general pur- 
pose operation routines have a ^ledfication of parame- 
len» further ooBqvming the steps of: 
g-16. defining a set <^ dau types that may be used to 
satisfy sakl spedfkattoo of parameters utilized in 
. said general purpose op erat ion routines; 
b-16. defining a set of parameter types that may be 
ntifized in said general purpose operation routines, 
including deffaiing for each of said parameter types 
an ■ nori s lcd subset of said dau types which may 
be used to satisfy said parameter types and a corre- 
sponding set of different dau type values wlucfa 
may be utilized to specify sakl dau types in said 
subset; one group of said parameter types being 
non-varying p aram e te r types having an associated 
subset of only one of said dau types; and another 
group of said parameter types being varying pa- 
rameter types having an a sso d a tcd subset <^ a plu- 
rality of sakl dau types; 
i-ld establishing a set of dau type parsmg routines 
each oomiming a set of instructums for obtaining 
the address and valiM of a parameter satisfied by an 
aisoriatrd one of said dau types; 
i-16. establishing a set of parsing control routines 
esdi associa t ed with one of said parametfr types 
and co mpr i sin g instructions for sdectably execut- 
ing one of a subset of said dau type parsing rou- 
tines correspcmding to sakl associated subset of said 
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data typesp said sabset having a single member 
when a parsing control routine is aisociafcd with 
one of said non-varying parameter types; 
k-16. establishing a set of command parsing modules 
each associated with at least one of sakl general 
purpose operaticm routines and comprising mstruc- 
tioos for executing of a subset of saiid parsing con- 
trol routines in pre-established ordered sequences, 
said subset being a null subset when each of said 
general pui po sc operation routines do not utilize 
any of said parameter types; 
1-16. storing each of said data type parnng roatiiies» 
said parsiiig control routines, and said 



parsing modules in said read only memory; 
g-16L defining an opcratioti code system compnsmg a 
plurality of opcode sets and a phiraltty of opcodes 
within each <tf said sets, such that each operation 
code comprises an opcode set designatioa and an 
opcod e designation; 
b-16. drfining a object code command syntax com- 
prising a set of bitmap bytes, a set of opoodt bytes, 
and a set of parameter type specifier bytes» each of 
said bttm^) bytes and said opcode bytes having a 
set of common bit positions com pris ing a byte-type 
flag and storing a first numeric value in each bit- 
map byte and a second numeric value in each op- 
code l^te, each of said bitmap bytes also having a 
set of c ommon bit positions comprising opset sped- 
fier data dements and a i^uzality of sets of common 
bit positions com p ri sin g data type data dements; 
each of said opcode bytes having a set of common 
bit posiUom co mp ri sin g opcode spedSet data de- 
ments; said <^)set specifier data elements in said set 
of bitmap bytes together identifying the opcode set 
of the command as a particular one of said opcode 
sets, said data type data elements in said set of 
bitmap bytes together identifying the data type 
values for all varying p aramr tr r types in the com- 
mand that do not c ompris e the defauh data type 
value; said opcode specifier data dements in said 
set of opcode bytes together identifying the opcode 
of the command as one of said opcodes; 
and wherein said step a. includes the steps of: 

(1) estaUishtng fSor each of said general purpose oper- 
ation routines an operation routme which utilizo a 
subset of said paranwtcr types, said scdnet being 
null for each operation routine that does not rc- 
(|uires any command specified parameters; 

(2) ittcoirporating into each of said general purpose 
opeiatioo routines one of said command parsing 
modules; and 

said step K includes the step of: 
storing said operation routine for each of said general 
purpose operation routines in pccarran^d rdation 
to said command parsing modules asso ciate d there- 
with; 

said step c. indudca the step of: 

(1) definmg for each of said commands a subset of 

wrf pOTtfi#»»r typg» m mil rtrrfwed Kat eomymd- 
ing to oae ot said ordered sequences of parsing 
control routittes in one of said command parsing 
modules, said subset being a null subset when each 

rrtmrn^nrf ^fy^t^ with ati n pmrina routine has 

an awxTsted auU subset of parameter types; 

(2) as sig nin g each of said commands to a spedlic one 
of said opcode seu and assignmg to each said cons- 
mand in each opcode set a different opcode in 
sequential numericd order; 
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(3) establishing a set of opcode jump tables each cor- 
responding to one of said opcode sets and compris- 
mg a sequential listing of operation routine pointers 
each com pr i sin g starting memory addresses for the 
one of said general purpose operation routines 
associated with the ccnnmand assigned to said cor- 
responding opcode; 

(4) storing said set of opcode jump tables in said read 
only memory at prearranged starting addresses for 
each of said tables in said set; 

(3) establishing an opset pointer table comprising a 
seqooitlal Ihoing of said starting memory addresses 
for said opcode jump tables; and 

(6) storing said opset pointer table in said read only 
memmy at a prearranged starting address; 
said step d. indudes the step of: 

fftt ^iyAing for each use of each of said commands in 
said application progiam module object code com- 
mands in accordance with said object code com- 
mand syntax; 
said step e. indudes the step of: 

staring eadi of said object code commands in said 
Implication program module in said random access 
memory; 

said step t faidudes establishing a command execution 
dau mncture indudittg an opset daU structure dement, 
an opcode data sUuctur e dement, an array of data type 
data structure elements, an array of parameter address 
and value data structure elements, a variable parameter 
traddng data dement, and a current parameter tracking 
data dement; 

said step fjf}) includes the st^ of: 
<>fryW"g said set of bitmap bytes and said set of op- 
code bytes to obtain an opset value and store said 
opset value in said opset data structure dement, to 
obtain an opcode value and store said opcode vdue 
in said opcode data structure dement, and to obtain 
dau type values and store data type values of all of 
said data type data dements in individual ones of 
said data type data structure dements; 
and said step f (2) indudes the steps of: 
(a) calculating the address of an opset pointer from 
said startmg address of said opset poixiter table and 
said value stored in said opset data structure de- 
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(b) reading the value stored at said ops^ pointer 
address; 

(c) calculating the address of said opcode pointer 
from said read opset pointer value and said value 
stored in said opcode data structure dement; and 

(d) readmg the value stored at said opcode pointer 
address as the address of the one of said genp^ 

asworiatfd with said 
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said step fl(3) includes the steps of: 

(a) first executing said command parsmg module 
aisoc i atcd with said general purpose operation 
roixtiiie at said address read in step f.(2) (d) above, 
including executing a«ociated parsing control rou- 
tines and data type parsing routines based on said 
data type values stored in said data type data struc- 
ture dements to read the parameter types in said 
object code c o mm a nd and to obtain the address 
ami value of each paramctgr required by said oper- 
ation routine; and 

(b) storing the address and value of each of said pa- 
rameters as they are obtained through execution of 



681 



4,724,521 



682 



said datm type parsmg roittiixes in indivklua] ones of 
sftid ptramcter and address data structure elements; 
(c) then execoting said operation rootines aOToriairri 
with said genera] purpose operaticm routines utiltz- 
ing one both <^ said address and vahie of each of 
^^said pa ramet ers. 
(^7' In ametbod for programming a local terminal, the 
vsteps of: 

^ establishing a tokenized interpretive p rogr amm ing 
i«Pg fM g <> having a plurality of commands and cor- 
responding syntax tndoding a sonrce level com- 
mand and parameter syntax, an associated object 
level m*""**™* and parameter syntax including a 
defined operation code for each <^ said commands, 
a p rogr am module structure, Iqp^katioD modules 

-r^aad'a compiler for translatinf^ source levd com- 
maixto in nid appiicatioo modules to said object 
kvd oommaiKl capaUe of being assembled and 
finked into binary code; 

establishittg a set (^operation routines for execntiott 
by said terminal to peifoim a set of tenninal tasks; 

storing said operation routines in said local terminal; 

definmg a set of commands ustng sakl source levd 
comma nd and parameter syntax, each being associ- 
ated with one of said operatioa routines; 25 

creating an application program co mprisin g a se- 
quence of sdd source levei oommanri in accor- 
dance with said program module structure; 
- compiliiig said application pr ogr am using said com- 
piler. 30 
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a»emblingt«Ml.^^ standard 
' im^^^^lS^rambM^u^^ 

communicating said program to said terminal for 
storage in local memory therein; and 

operating said terminal using said application pro- 
gram. 

IS. The method of claim 17, wherein said step of 
compiling comprises the steps of establishing a first 
section df'^mpiled code c o mpri si ng a fixed code struc- 
ture that defines the environment of the application 
progi am and a variable code structure that comprises 
porticms of the ^jpBcation p iogi am that vary with the 
content of the program created in said creating step 
whereby said ^ 
assembling and linking step creates a corresponding 

fixed binary code secticm aiKl a variable binary 

code section; 

and said step of communicating said application pro- 
gram compr i ses first communicating said fixed 
binary code section and storing it at the local termi- 
nal and then conmiimicating said variable binary 
code section atKl storing it in the local terminal; 

said fixed binary code section stored in said local 
tenninal providing information for accessing por- 
tions of said ^^licaticm program in said variable 
tnnary code section stored in said local terminal 
wiaHe performing said step of operating said termi- 
nal using said application program. 
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it attractive to mass produce and 



deploy computer based systems which employ inte- 
grated circuit technology. One such system application 
is the point of sale transaction terminal fbr credit verifi- 
cation and credit transaction data capture. Another 
api^ication is the automated bank teller terminal which 
enahiri the unattended performance of a number of 
types of banking transactiotts. 

Other applications involve a wide variety of local 
data capture tcrminab which communicate with a re- 
mote host com pilfer. It is anticipated that such system 
appl i cati o n s win eventually extoid the technology into 
home baidring terminals for transfer of money between 
accounts, auf o maln l payment of bills, and potentially a 
wide variety of other financial and non-financial traio- 
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The principal customers for point of sale transaction 
terminals of aQ types are major financial institutions, 
mdudtng banks, savings and loan aqociatiom, and 
credit operations of major chains of retail stores. For a 
variety of reasons, different customers for point of sale 
transaction terminals need or desire to customize the 
functions of their terminals. Banks and other financial 
institutions are in the process of extending their waUs to 
the merchant's duckout counter and point of sale trans- 
action terminals are a major factor in this extension of 



For strong merchant acceptance, the features of point 
of sale transaction terminals must be tailored to meet the 
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spedficaDy perceived, different needs of each of the 
Cerent merchjuu grottps that represent the ultimate 
customers for the tenninaL Even among merchant 
gnmps where the services needed are essentially the 
same^ there is no standard approach to proviUmg these 
services. Thus to satialy the needs and demands of the 
marketplace; point of sale transacttcm terminals most be 
able to be costomized for the paiticular i^ypBcation at 
which they are dir e cte d. To achieve this result, the 
coo ipot c r prognm being e x ecu t ed by the local com- 
puter system in the local terminal must be a custom 
appiicatiott piogiain. In addition to providing point of 
sate tr a ntar . iirm termittals initially with custom applica- 
tion pfOgramSp customers wiO often need or desire to 
alter the appllcatiou program to add or change a feature 
or to remedy a problem or deflect disc ove red in the 
program after the terminal is mstaUed. The customer 
dcsirmg or needmg a program reviiioo may have a large 
' of tenninals pliyaicaUy located at many difler> 
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2- Prior Art Approaches to Oiilcnn Terminal 
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Ptoviding custom ^>pGcatioii programs for point of 
sale transactioD tenninala results in ina|or problems for 25 
both the vendor of the terminala and the customer. The 
itaiidard approach to |>"^«a*ww»wig a local terminal Is 
to load the appUca tioo program into cme or more inte- 
grated cixcutts of the progranunable read only memory 
type and then to physically install those program mem- 
ory ci rcn i ts in the Inmiiials to be supplied to the cus- 
tomer. If the vendor is suppiymg In Hiiiials with di£Ger> 
eiU c u st om ^ypbcation programs to a number <tf differ- 
I there is a basK problem associated with 
I scgir gated inventories of the diflferent pro* 

In a typical case of generating a custom application 
p ro gram for a partimlsr customer, the pr o gram will 
evolve through several versions befbre it achieves 



to mhsnry the program to meet competition or to keep 
up with tht growing needs or expectations of the mer- 
chants or other parties that are using the terminals in 
their day to day business operations. 

y Prior Art of Downloading Program Information 

The point of sale transaction terminals of the type to 
winch this mventicm is directed are invariably installed 
with a commmriration link to a host computer. This has 
lead to consideration of implementittg one solution to 
the logistical problem of updating existing terminals in 
the fidd by communicating the new program to the 
tndividttal temnnals in the field via the communication 
link with the host ccanputer. 

It has been known in the art for some time that it is 
feasMe to download limited types of control informa- 
tioo to a local terminal to alter the manner in which a 
relatively fixed local i^iplication program b executed. 
For example, there are systems in which the prompts 
presented to the operator of the terminal may be down- 
loaded from the host to the local terminal. This may be 
done in a static sense, with the downloaded information 
stored in memory at the local terminal until it is 
changed by the host. Aitenutftvely, it may be done in a 
dynamic mode; with the host controlling the prompts in 
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It has also been kmiwn in the prior art to download 
from the host computer to the local terminal certain file 
and control information to be used by an otherwise 
fixed pr o gram in the terminaL For example, it is known 
to download such information as the telephone number 
for the tenninal to dial or log-on information for access- 
ing a remote net w or k . It b also known to download a 
control string which controls the building of a dau 
packet for transmissaoo from the local terminal to the 
host computer. Control string downloads have also 
been used to control the files in which responses from 
the terminal are stored. 
There have also been limited implementations in the 
&ctory iimctkmality. When the pt o gram b accepted by 40 prior art of downloading of entire machine language 

application programs from a remote computer to a local 
terminal with storage of the downloaded program in 
battery protected randtmi access memory circuits at the 
local terminaL In tins case the read only memory cir- 
cuits at the local terminal contain only the programs for 
basic management of the download of the application 
pr ogr am together with the operating system for the 
basic program control of the central processor unit in 
the, terminaL 

While; on the surfKc; thb approach to custnnizmg/ 
the appficatiop programs running on point of sale trans* 
action termiaab may look attractive; there are several ^ 
reasons why a complidus marhtnr language program ' 
jdcgifidjM ^ IMincipal reason b the 

Siitt^ tli^^^»S;*>wtMfc/ t»Tigi Mgy . : ^ ^ thl^ fhl? ■ rifft g 

rcqiiirnl «6^^^ / 
"uaL^It b'^noc practicaUe to author the custom applica-;> 
tioo p ro gram dircctlyi<in»machine famgnage because of ^ 
the scarcity of programmers who can author programs 
dhecdy in marbinf hmgoage.rConsequently it b neces- 
sary that the inogram be initiaily written in a high level 
language sndi as the C-langoage or Pascal, and then 
com^^ed^ud^Mked^^ 

cbdeT'^S^M^Sinwandwlinker inherently produce a 

equivalent |»ogram writteiB Ir/ a creative programmer 
directly in marhinr language. 



the cust om er, typically thousands of tcimina b are ddiv- 
ered and imtalTrrt at widely separated g eo grap hic 1og» 
tima. Even with exercise of great care in dcvrioping 
and testing the pr o giam befbre deitvcring large quanti- 
ties of terminals* it b very likely that certain minor 45 
program deficiencies wiD be detected by tisers of the 
terminab during the first few weeks and «**>«*h* of 
operatuo. 

If the ap p Kc a m wi program b stored in the local termi- 

1 read only memory, these program » 
I can only be remedied by revising the apfrf^ 
i program, londmg it mto new memory circuits, 
and thai installing the new m em ory circuits in each of, 
the teiminah by vBiting each tnstallatioo sbe or by 
brmgmg the If iiiiiiisls back to a central &cility for ti>- 55 
staUation of the new pro giam uiem c My circuit. Thus 
cadi Dfooram dttune causes an expensive 



60 



consuming logistics problem with aO the atten d int dis- 
ruptions of the buiiutja of the caitomrr . 

The problema encountered with remeilying program 
deficiencies are also present when the vendor and cus- 
tomer oontem|rfate a program change to add or change 
features and wish to modiiy some or all of the terininab 
that are already irmanrTi in the field. The logistical 
problems tend to discourage enhancing the 
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programs being executed m the terminab after satisllMs- 
tory operati o n of the initial piogiam has been achieved. 
Yet it b <^ten very importam to the customer to be able 
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This Urger code size is not a problem when the code length suhnanriiDy sinrter than the code length of the 
is directly loaded into read only memory program or- operation routine. In accordance with the method of 
cults (or physical insertion into the local terminal be- this invention, the local terminal also has a program 
cause ■tttOTnatrri programming systems are ai^ilable to established in its read only memory system for inter- 
load the code mto a number of read only memory cir- 5 prying the operation code to ■^''t*? the associated gen- 
ctdts smuhaneously. The larger code sixe becomes a ^f^j pmpos^ operatkm routtne for execution by the 
problem only when direc t downloadittg of the entire central processo r unit The object code version of the 
cod^ mto the local tenn^ 13 om^ application program m tl» form of a sequence of com- 

ToiUustr^axo^uledandhnkedvm^ mands has a code size which is several times smaUer 

cat ap^icattoo program may comprise 32 kilobytes or 10 ^ comoiled code size would be for an entire 

code. Mott local terminals communicate with tl» host 3^ZL^ HiLJ^ 

skm fate; download of die apphcatioa program to the ^ mvcmtiott m- 

local terminal win take abofrt^minuteTlte might be .5 dudes a first step ofestabhshmg a set of general purpose 

acceptable if there wero only a lew terminals to down* operation routtnca to be ciecutedb^ 

kaadfktn the remote host contputer. In the typical case, »y»«oiu Each or these general purpose operation rou- 

tt may be necessary to download several thousand local tines comprises a set of mstructiOBS for ezecution by the 

*m ^w,nA^im A mm^im^ m A^^tnmA fj^^-m ^^tm* Central pTOcessoT ttuit itt a prearranged manner to ac* 

tm ^i»*im Aw m lo^i^^ M tr%tmi r^jin^cm mtfitifi^m ^ comptish a spcofic task. The ucxt Step IS to stoTc thc sct 

1000 boon of dowttloadiag *^ would be required. If <^ genera] purpose operation routines in the read only 

the downloading were done by a single host computer m e mory of the local terminal so that they may be ac- 

during the twelve htmrs between 8 pm and 8 am, it cessed for execution by the central processor unit. The 

would take over 80 days to (townload aU of the tomi- storage loc ati cms of these general purpose operation 

nmim. u ^ >hn* api^awmf tK»f th^ ft ^^wmY^ ^^^yiM ffj/y^^tT^ ^ rontincs Will be a i i aug e d and noted so that the routines 

a oontplece machine language appHcatkm program n can be addressed. 

imprai^icabie where a large number of terminals are A following step is to define a set of commands, each 
mvolved. of which is associated with a specific one of the general 
SUMMARY OF TTmn^nn^NTTOM purpose operation routines. Each of the commands 
SUMMARY OF THE INVENTION ^ wcbuto at least an operation code relating the com- 
1. Ofejecta of this Invention mand to its associated general purpose operation rou- 
u iy »fMy pr itiffip ^ objtct <yf tffvytityw to pTP*ady tine. Each ofthe commands is defined such that it has an 
an improved mf^b r d of operating a local tyr minal to associated comm a nd code length substan tially less than 
mfrvt^ a fmrtwn afrflicatimi the ccxle length of the associated general purpose opera- 
It is another object of this isvcntiaa to provide a ^5 ^'oa routine. Preferably, for convenience of writing 
practicable method of operattng a local terminal based programs, each command n defined with a high level 
00 a custom application piogram downloaded firom a programming syntax in v^iich die cominami is repre- 



sented by a series of word fonu in abbreviated notation 
. which have a recognizable association with the task that 

1 Features and Advantages of dus Invention ^ the associated general purpose operation roudne wiU 
a. Reduced Code Size for Applicatioo Program perform when it is rxecnted by the central processor 

Download unit in the local feerminaL Thn high level form of the 

Thisinvendoafcaturesamethodforoperatinsalocal is Uten ccMnpOed and assembled to produce 



I Which includes a computer sm comprising the operatioa code wluch relates to die associate^ 

s central processor unit, a read only memory o^ ^ ^ purpose operation routme m a manner which is 

the central processor unit, a random acceasmmory iateffigible to the mterpreter program in the local termi- 

tioo channel coupled to die cemral processor unit for ^^^^ these for^omgrte|»tove been performed, 

^tfSMWMwAi ^ffng ^ rrT*9* f n rnip u f f f Tytrtm O ****^ then next step m the method of this mventxmis to estab- 

ispat devices, sadiM keyboards, PIN code entry pads, ^ li>lt » the remote computer system at least one i^iplica- 

ardieah f a , nd the Kke amy also be p rff^w frrt m the t""^ program module conqvisittg a prearranged se- 

lfte»l termm*! Tho ffiyff i^ytf nf frKW p'TT^ ytf^ ft qucnce of the cotHmanrH which have been defined. This 

pr « r»ir , t f|f ap proa ch to downkMdiag an entire n*t*rT n application program module b written such that, when 

*rf^!i*aiiB n piugiam frtrawtf the size of the p w ^ww the associated general purpose operation roudnes are 

sode required to be downloaded is reduced by a &ctor 53 executed by the central pro cessor unit in the local ter- 

3f three or four by avoadmg the rapdrement of down- minaL a meaningful series of tasks associated with the 

kMdmg aQ of the actual machine code ui st nictions of desired ftmcfionaBty of the local terminal will be car- 

Lhe appficatioB program. ned ouL Typically, a custom appBcatioii program run- 

lottead, the method of this invention b based on n>o8 m * pomt of sale transaction teraunal will utilize a 

itorittg m read only memory circuits withm the local 60 multiplictty of a{q;>lication pr o gram modules which will 

xrmmal a number of general purpose oper a tion roo- be called for execution in a parttcnlar sequence to carry 

ines which co mp ri se instructions to be executed by the out a compkie transaction. The simplest and broadest 

»itral process m unit to accomplish a particular pro- form of the invention, however, contemplates that there 

jram task. Each of these general purpose operaidon may be one or more application program modules, 

routinesfa atiocisted with a defined commaiid which, in 63 The next step in the method of this invention b to 

.ts object code venkm, inchides an operati on code. The communicate the application program module from the 

abject code versitm of the commandi aworiatrd with remote computer system to the local computer system 

the general purpose operatioa routines has a code via the communication channel. Thb includes the step 
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of Storing the o p er a t io n codes asiociated with the prear- 
ranged sequence of commands in the random access 
memory of the local terminaL 

The mediod ftmher tnchides the step of establishing 
in the local computer system a program eiecutton roo* 
tine for rnaWing the central pr o cessor unit to execute 
the application |m>grun module; This is accomplished 
by repetitively p er formin g the steps of: 

(!) reading one oi the operation codes stored in the 

(2) arcrwing a specific one of the general purpose 
oprration routines associated with the read operation 
code; and 

(3) e ie cot in g the a cces s ed general p oi pose oper a ti on 
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nals being sold regardless of the application program 
which the terminal win run. Random access memory is 
provided tot storing the application program as well as 
alterable parameter and ffle information. Thus a termi- 
nal can be completely manufactured and inventoried for 
sale to any one of several ultimate customers having 
differing application program requirements. Prior to 
delivery the standard terminal can be downloaded with 
a standard application program or a custom program 
provided for that customer alone. 

In initial programming of the local terminal, the 
download of the appJkatiott program into random ac- 
cess memory terminal can be accomplished by a high 
speed direct data link* such as through the RS232 port 
commtmicating with a previoQsly downloaded temiinal 
at 9600 baud. This eni^iles initial programming of the 
additional local terminals within less than one minute 
each, typtnlty. Then after the terminals are installed 
and opentittg in the field, they can be conveniendy 
repr ogi ammed to eliminate program <teficsencies or to 
add cnhanord features by downloading via the tele- 
phone lines through the mndrms at the host computer 
and the local terminaL 

In ■*Hf*vwi to the core |M»|^ i a ««mtng ami program 
execution feature of this invention and its advantages as 
part of a method of operating a local terminal, this in- 
vention includes a number of other, related advanta- 
geous features: 

(1) the methodology in which operation codes are 
grouped in plural groups and are defined at the object 
code levd using a bitmap/opcode system. 

(2) the methodology for handling speciftcaticm of 
parameters within the defined commands and indicating 
the data types of varying data type parameters u»ng 

elements integrated into the lntmap/(^>code sys- 



It win be appreciated that the core methodology of 
dds inventioo provides a omnber of advantages which 
makes it pncdcahie to download castom appltcatkm 
programs in terms of the time required for the down* 
hMi^ng. As win be better understood fiora the detailed 20 
descriptmn given bdk>w, the m et hod <^ this invention 
involves a coostractive and feasible tradeoff of (wogiam 
execution speed at the local terminal fiDr spped of down* 
ksading the custom apnlication pn^ram. 

The speed of execution of the application program by 25 
the local tenninal is reduced because of the st^ in- 
volved in " interp r etin g^ the oprratkm code to access 
the associated general purpose operation routine so that 
is can be f i tficuni l by the central processor unit. This 
interpreting step is not present when a mnrhinc Ian- 30 
guage program stored in the local liTtminal is directly 
execute d. It has been fmmd, however, that this reduc- 
tion of speed of execotimi at the local terminal is not a 
problem proviilcd that the p rogr am execution overhead 
which is occ up ied by the interpreter program is kept at 35 
a manageable leveL 

Fufdiermocc; the tradeoff m ovenn speed of execa- 
tioo can be rednced by creative anthonng of tiie general 
eratiott routines as hi^y efficient machine 
Mitines. Since this a ut h or ing is done <mly 40 
, it is feasible to have a very skilled macltme Ian- 
rammer spend a substantial amomM of time 
to optimixe die code of each routine. Hie set of routines 
can also be optimittd to the type of transactions which 
are p erfor m ed by the k)cal terminaL When this b done. 45 
some of the time that is lost in accessing the general 
purpose operation routine to be executed can be made 
up in speed of execution of the rootme hadf. 

hlore unportaittiy, it haa been found tfaatp with cre- 
ative imptementatioa of the core concepts of this inven> 50 
lion, it is poaaibie to reduce the downhMd tone for a 
custom application program by a Actor of two to three. 
A pr o gram which migfat oth er wise take ^ mimites to 
download, can be downloaded in ^lout 7*10 minutes 
using the method of this mvention. This dramatic rednc- 55 
tion in download tune makes it feasible to download a 
new version of a custom program into a large number of 
local temunah withm a reasonable time frames 
The method of dds mvcntioa dras avoids an of the 

togistic proM ems associated with the prior art apiroach 60 * ^ 

tendi ng the custom program into read only memory ' Hus programming methbo-aisOmvolves establishing^^' 
drcnits physically insttlled in eadi of the local texmi- asetofoperatiooroutinesforexecntionby the terminal 
nals. Instead, die focal terminal is provided with read to perform a set of terminal tasks. These operation rou- 
ooty memory for storing the operating system and the tines are stond in the local terminaL An additicmal step 
general pwpoae operation routines as wen as the other 65 m dds method b defining a set of commands using the 
kKatty resident programs modules aiid fiKtlities which source levd command and parameter syntax, each 
are required to implement the method. These read only being associated with one of the defined operation rou- 
memory circuits are common to aU of the local termi- 



(3) the methodology for establishing general purpose 
operation routines which share program factltties 
within the local terminal for parsing the parameters 
whicb are included within the defined commands. 

(4) the methodology of integrating paramrtrr parsing 
routines and control of the sdection of parameter pars- 
ing routines for varymg panmetera satisfied by differ- 
ent data types using data type data elements induded in 
a bftmap/<^icode sy^em in the object code command 
syntax. 

b. The Programming language Feature of This 
bivention 

This mvention also features a method for program^ 
ming a local terminal which involves the key step ai ^ 
estahUshing a mkrwiTrd interpretive programzning hu^ 
guage system having a source levd command and p*- 
rameter syntax, an associated object levd command and 
pa ram e ter Sjfntax jnciudin g a defined operation code for . 
each^.pMhe-«omttands, a program module structure, f 



rteVd comgaSas Y 
f^tntQ binifycbde. ■,\ 
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After these steps have been perfonned the next stq> is 
creating m ^g^^o p^oa^moM^^ the sou rce 

* ivith th e itfogrm mod ule sui kimer l to'SToUowS^ 
' co!pp^W*ft thfe iCTTlication progmn us> wg"tli c P^MnpAy r"!: 
and thcnSiwffia^^a^a^^ 



ptb g ir nm r^nie Msembied and linked program is then 
-eommiSaii^ to the tenninal for norage in local mem- 
ory therein; and then the terminal is operaled nsing the 
stored application prognm* 

This methodology provides the capabilhy of whkv- 
ing higher jh ogritnwiing productivity because of the 
hig^ level nature of the commands. The commands can 
ntilixe names which are self-documenting for 

the task that the s s io ci a ted ^neral piffpose opention 
routines wiO p erfonn at the local tenninal The use of 
operation codes at the object code level of the com- 
mand syntax provides the co mp r ess ed doiwnload code 
Cbatare of this invottioii. 

c. Concuirent Scheduling of Applicatioa Program 



A second principal feature of thb invcnticn mvolves 
providing a methodology for psuedoooncurrent exccu- 25 
tion of applicatiott program modules. This methodol- 
ogy involves pnyvidrng defined commands which can 
be incorporated within one a^ilication program mod- 
ule to start the eiecu ii uM of another application pro- 
gram module ooncurrently or to cause one of the active 30 ticing the method of this invention. 



cation program development tools facilitated by this 
invention can be optimized for the types of transactions 
besttg carried out by the local terminaL Furthermore, 
the overall methodology of this invention makes it pos- 
sible to create a high level, pseudo<oncurrent program 
language which fimlitates the development of custom 
application p rogr ams for point of sale transaction termi- 
nab. This invention strives the difficult problem of man* 
ageable application program download times. It thus 
10 encourages users of point of sale transaction terminals 
to inc(»porate features and luncticHis which msTimire 
the utfllty aixl value of the local terminals in the busi- 
ness environment in which they are deployed 
Other objects, features and advantages of this inven- 
ts tion will be apparent from a consideration of the de- 
tailed desdipdOT given below in conjucdon with the 
accompanying drawings* 

BRIEF DESCRIPTION OF DRAWING FIGURES 

20 FIGS. lA and IB are iOustrations of a local terminal 
in which the method of this invention may be practiced. 

FIGS. 2 and 3 are block trhrmatir diagrams of the 
drcnitry of a local terminal in which the method of this 
invention may be practiced. 

FIGS. 4A and 4B iUustnte an operation bitmap and 
opcode system useful in practicing the method this 
invention. 

FIGS SA, 5B, 7 and 8 fllustrate alternative version 
of bitmap and opcode systems that may be used in prac- 



application program modules to wast or suspend its 
CTecuti oii in favor of going forward with e x ec u t ion of a 
diCTcrcttt active applicatioo program module* and by 
establishing a h ti fa lfT pro g r a m to schedule the execu- 
tion <tf the active api^ication program modules so that a 33 
ap p roach to starting and 
I of mdividual active appbcatioii pn^ 
. The preferred schethiler pn^ 
gram feature indndes methods for giving priority to 
active application pi o giam modules that need input 40 
from input devices or a timer. 

This feature of this invention provides the advantage 
of greater flexMity in the structuring of application 
program mo d u les to maximize the use of the program 
executioa capability of the mi cr opr o ce ssor withm the 45 
local terminaL The trherity^er p io g r am facility and the 
ai a nri a trri features of the defbed mmmanrit that are 
integrated with the sdiedukr do not provide the capn- 
bOity fSar two applicatiaa program modutes to be acta- 




! the pi D granu nef to 
leave the tfifitent a pp li c a tion program modules that 
are active in the local terminal at any one time period in 
such a way that it appears that a number of tasks are 
being carried out at the same time. At places m the 53 
^ i rf- ^ ' iitk^ of a particular appficanoo pr^ram module 
where it cannot continue to execute without waiting for 
mmfthin g to happen, sndias waiting fbr a partinilar 
input to be received, or waiting fbr another application 



FIG. 9 illustrates a preferr e d system for storing and 
amming operatkm routines and parsing routines in 
accordance with this invention. 

FIGS 10 and 11 illustrate alternative systems for 
stormg and accessing operation routines and parsing 
routines in accordaiKe with this invention. 

FIGS. 12A-12E illustrate data structures and data 
element bit assignments useful in practicing the method 
of this invention. 

FIGS. 13A and 13B Ulnstrate data structure and data 
storage arrays oseftil in the parameter parsing methods 
of this invention. 

FIG& 14-22 are flowcharts iUustrating routines asso- 
ciated with execntmg applicatiott program module 
commands in accordance with this invention. 

FIGSb 23-26 are flowcharts illustrating operation 
routines associated with application program module 
dnwimanria provided in accordance with this invention. 
FIGS. 27 and 2S are flowcharts Hhmrating altema- 
Hbwever, the schechiler 50 tive routines for exemting application program module 



In aoc onia ncc with this invention. 
FIGSw 2>-^ are flowcfaarts illustrating routines use- 
ful in implfmntwg the concurrent appfication program 
module schediding methods of this invention. 
FIG. 33 illustrates a system for storing and accessing 
m accordance with this 



FIGS 33-3S are Oowdmrts iQustrating routines use- 
ful in fan pl emc n ting the concurrent applic^tK»i program 



pro^pm module to finish hs execution, the current 60 module scheduling methods of thb invention. 

FIGS 36A and 36B illustrate an alternative routine 
and data rfrmrnt bit assignment useful in implementing 
the concurrent application program module scheduling 
methods of this invention. 
65 FIG. 37A illustrates a compressed state table storage 
and accessing system useful with this invention. 

FIG. 37B illustrates a state table lookup routine useful 
with this invention. 



application program module may suspend its execution 
with a WAIT command, so that other application pro- 
gram m odules can proceed with their execution under 
the control of the scheduler. 

From the above summary of the features of this in- 
vention, it should be apparent that this mvention pro- 
vides the capability of structuring operation routines 
and commands associated therewith such that the apph- 
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HGS.3S-47 are flowcluits Olustraniig rotttiites asso> to keys having the nuiDerw labels 1« 4v 5, 7» and 8. The 

dated with application prograsi module commaods keys in section 14B senre as calculator function keys 

oseftil in implementing tfaii invention. and the keys in section 14C serve as tenninai function 

FIGS. 48-55 are flowcham of routines which are ^^y,^ 

useful in connecdoo with implementing this inventicm. 5 xhc standaid functions that the ZON terminal per- 

DESCRIPTION OF EMBODIMENTS OF THE standard and programmable teiq>hone dialing 

Q^VENTION operattoos, four function calculator operations and 



BACKGROUND ENVIRONMENT OF THE 



point mi sale transactxoo terminal operations. 



INVENTION 10 a. The Telephone Function 

This ittventiott involvea a method for ope ra t in g a Standard telephone dialing may be performed by 
local terminal to e x ecute a prearranged appHcadoo using the keypad on the telephone handset. In this 
P*^>ffm which hn b eat do wnloaded imo the kxal nxxle, the handset is directly connected to the tdc- 
tenmnal from anot her co mputer system. Execution of ^^^^ ^ when the handset is lifted and the keyed in 

2^^5d&^oS^ wittothchandsetasthemdiv^ 
local tenmnal is decficated* but may be altered by down- l**««d. ^ ^. „ . ^ ^ 

k)ading a revised applicatkm progiam from a remote Tetephone number dmlhig may also be done as a 
fi? m|w w 20 ivc^nmmed feature of the terminal with tlw handset m 

^ place. When the -PHONE** key in section 14C of the 

1. mustntive Ezami^ of Local Terminal Features and keyboard 14 is depressed* the tf p"*"*i enters the 
Opention (FIGS. lA and IB) -phonc^ rtate and d»e keyboard section 14A becomes a 

The inva»tion wiU be ilhistrated by discussing its use tetephooe keypad for a computer telephone function. In 
in a specific local terminal application, namely a point ^ this state» each of the keys labelled 0-9 invokes a DIAL- 
of sale tr an saction terminal of the type which is pur^ DIGIT action which is a predefined read only memory 
chased fay a retail mochant through a credit provider resident task of the ctxnputer system within the terminal 
■Jo<»l bank for ^le purpose of carrying out god causes an appropriate tone to be generated ami put 
credit transactions with customeis and related data out over the tdephone Gne. It causes of the 
(^tu» ftmcdooa. It shouM be » dialed digits to be stored in sequence in a reserved mem- 

Sl^f. USSL"* w """^^l^^ ^ "^J^ <^ Mccamns using the REDIAL key in 

termml yBcyo p, ^tttMU bensed m a nu mber of ^^^^ 14A. This fbnctira of the terminal a an integral 

iww* ,4 the terminal as will be dtscntifd below m connection 
irnMWf nose computer* » • # • i. »_ i^ 

FIG. lA depicts a local terminal sold by Veri-Fooe, ™ contents of a generK program which has been 

Inc. of Hooohihu Hawan, nder the tiviemark ZON. prepared for the ZON terminal using the method of this 
The tennhial 10 ^*n -p*- ^ a buse unit 11 and a tete- mvention. These partcubr individual fuDctt(»s are 
phtMlmrfMt iXThfth«M>ii»;t|y h wyf ^ pf pt^ predefined ROM functions in the ZON terminal and are 

meric dsplay 13 having sixteen characters, a k eybo ar d 40 accessed from the state tables* but it should be under- 
14^ a cardreader IS* a speaker 14C and a speaker vohnne stood that they could also be application pr o gram mod- 
control IT The handset U incfaides a handset ringer ule ftmctioos defined in the application program itself, 
switch 18, traasoistter momhpiccc 19, a hang-up buttcm The terminal also has a mcnK>ry speed dialing feature 
20, and a telephone keypad ZL The telei^KHie keypad which permits up to eight frequently used telephone 
21 is optional since, m wiD be discussed below, the 45 numbers to be programmed into the terminal, stored in 
tel ephon e dialing fu nct io n can be a cc o mplt a hrri using a memory in the terminal and later aufcomaticaUy ^^^i^-rf 
^raficss^ioa of keys on the keyboard 14. The handset by the computer system within the terminaL The details 
Uu cmmycd to the bwem^ U by way of a standard of the programming of these phone numbers is not hn- 
"^SJh^ffi^I^S^W^ VI portant to this mvention and win not be discussed here. 

Tt K^^ho wn) of the b ase umt 11 » » Once the numbers have been stored, the memory speed 

lar lai gp auM jacfc ar cosmectmg tty unit to a tetephooe accessed by seonentially deivessina the 

outkL It also has a nhis into which an ootional PXN. rTTZ? " T^^TTf , , . ~. 7 73~T* . 
™ .Trr *7 * Tv^ «B wpwMi PHONE and RECALL kevs in section 14C of the kev- 

(Personal iH>wiinri^iT*^ | Number) Psd may be coo- ^ * 7*r ^^^^ ^ » « 

Lcted. a serial part comJ^' a pSuS^LTa ^ f>^tw^^ 
to comiect to i^ower pack for si^p^ elect^ « andl6onthekwid^^ 

powertotheuniL71iebmumthc»^^ the tammal proto » ^^^J^e tone c^ 

circuitry of the terminal which is shown in block di*- ^P * ™"'S ^ the digits m the stored phone number. This 
gram fbrm in FIGS. 2 and X standard speed dialing function which is available in 

Relierring to FIG. IB, it is seen that keyboard 14 has ™^ ^ ^ computer-based tdephooes and need not 
three sections of keys H>«S gfit>^ |4b^ ^ 14^ ^ be de s ciib ed in detail here. These functkms can be al- 
gnu pr ^i^ p g ^ total of twcuty-eight keys in alL Each of ^ altering the applicatiott program, for example, 

the sections of keys serve multiple functions which ^ altering the number of phone numbers that can be 
depend on the state that the terminal is in. The keys in stored, or by altering the particular keys on the key- 
all three sections serve as alphabetic letter input keys board that are utilized to access the features. The termi- 
with the parttmlar letter assigned to each key shown as 6S mU is programmed automatically to return to the 
a label above the key. The keys in section 14A serve READY state when the handset b replaced. This can 
also as numeric input keys and transaction host selection also be changed or redcffaied by the application pro- 
keyL Note the identifiers of the major credit cards next gram. 
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I 1 the fettuns of the terxmnal or ^ combination of the two. 

b. The Calculttor Fwactixm foOowing general ftmctional areas of the 

The calculator function is accessed from the READY terminal can be customized: 
state of the terminal by pressing the CALC key in sec* ** data entry 
tion 14B <^ the keyboard 14^ The display responds by 5 •* packet communication 
displaying *XALC*, and the keyboard sections 14A •« data capture 
and 14b then become mmiber entry and math function local processing of dau 

keys of a regular fbur-functicm calculator. Hie fbnc- unassisted batch data transfer 

lions of the calculator feature of the terminal are aho •« report generation and printing 
prcdcfinffri ROM resident fbnctions accrwH from the tO *« receipt slip formatting and printing 
state tables* but these fbnctioas could alternatively be «« pn< entry for identity verification 
defiiicd in the aj^fication pfogram itself. The can be custcMn programmed for control 

c. The Transaction Tcnninal Functioos ^ external devices, such as the PIN pad for entry of 

personal identification number and printers which may 
The basic tr ans a ction terminal I mction is cre^ 13 be attached to the terminal to ]»int receipts or reports, 
fication related to a sale using the cu s l o mer s credit card control of other devices which can communicate 

and other die maimal or credit cart rea^ with die terminal over die RS2»C interface, 

entermg the credit card data. Tabic V a tt ach ed hereto 

ilfaHtrates the openttioQ of the terminal in a typical 2. IDustntive £iam|de of Local Terminal Hardware 
frff.|^ft^yfi^ <*«;tij th* <>».prfi# iiMiriwiH Ti^ tn Environment for the Inventiott (FIOS. 2 and 3) 

which ack cta the ho rt autonyt icaUy s^ up the termiMl a particular local terminal hardware environment in 
to di al an aww opny ^e^m nmbcr to mxxu the ^ method of dus mvendwi may be practiced is 

Bost com pcter Ry tne cr edit card tnat a DCTig ttsea in flh»trated in die block diagrams of FIGS. 2 and 3 and 
r^ooae to the d|,pl«y prompt tp ento" die acxwim wifl now be described. The hardware iOustrated m diat 
aTSL^^T^^'^IIS^S^^ of the ZON terminal depicted in FIG. L However, it 

^L^H^oT^^ tL'ta^^ ^?di^av nralmfla ahouW be understood that die method of Ulis tnvcndon 
e^T^^Z^^hm is a general one and can be applied in a number of differ- 

sale, fol^ by depreSooftbe EKTER key. Once '^'^^^^t^ ^^liV* 

die ENTER key is depieascd. die terminal takes over 30 'e«*^iiinmi« of hardware eie^ 
the processing of the tjansactkm. The host computer is uscor tiic mventMm. 

dial^^tettLsacd^ information is transidttSdaver ^ ^ ^^T^^SJT^ ™' ^ fllnstrates gen^- 

die phone line; die approval mformatioa is received ^ ^ example of a hardware sy^em environment m 
ton die host compi^. die appioval mformatioa is ""^^ ^ mediod of Uns invention may be practiced, 
displayed to die operator for noting on die credit slip 35 Loc^ tominal 10 includes a mimcomputer system 30 
and the terminal ^jtr rr nn rrt s Depressing the HANG wmch imorp oCTtcs monory and mput/output circuits 
UP key terminata the fuactioii and letuma the terminal which communicate with and control speaker 1^ card 
to the READY f*f^ reader 15, display 13, and keyboard 14. Optional PIN 

The manual entry mfthod shown in Tabk VI is uti- P^ ^ '"^ prmter 39 are also controOed and communi- 
fi**4Tfthg "«« g'*T**^ «*np^^ thrnmTffnf*^^ ctrdit cart 40 cated with by the microcomputer system. A communi- 
is damaged. The transaction prrf cffdf in the man* cation i'h fl nnri , comprising tone gene r a t or 31, modem 
ner eacept for manual entry of the credit caid number ^ telc|rtione interface 33 is provided for communi* 
and the »«p ir» tWyii <ute of the card m re sp on se to cation with a remote computer system 37 via telephone 
prompia on the dis^y of the terminaL co mpan y tines 34. The remote computer system will 

The terminal ia also pcogrammed to '^^f^ recall of 4S typicaOy also have a modem 36 and a tdephone inter- 
the information transnitted and received during the last ^ as so ci a ted therewith. As wiO be explained in 

"•"i^ ^ ^ »K> »^i* mMMl tiMt ff more detail later, this communication channel enables 
UP key is deptcsscd. Another featnrewltfdi is provided ^ terminal to receive a download application 
inthetermitty isncoesstottseoftfaeMcDoiineaDoiig- ptogr am for storage in the memory circuits of the mi- 
laa • V ^f f ^ H ' draft capture system fbr f f i pt ^ i rii ig infor- 50 crocomputer system. This same cranmtnication chan- 
matioo on i ri i Mat lim w in a batch p* «** ^«" »>fl mode. thereafter serves to enable the local terminal to 

Data on sales, voids, and credits can be entered as well communicate with remote host computers to peiform 
aa doing post transaction author ii at iottt, transactton credit verification functioos and/or data capture fonc- 
batch inquiries, batch reviews in the forward or reverse tions as generally descr ib ed above. 
dir ection, and other standard fum^tium of the McDoo- 55 It should be understood that the remote computer 
neH Douglas system. system which performs the application program down- 

load to the local terminal is not necesurily involved 
later in the credit verification fonction. The local terms* 



d. Standard and Custom Terminal Features 



It should be understood that, using the method of this nal may be communscatittg with several different host 

invention, the features which are provided as standard fio computers for verification of credit relative to different 

foatnresof theterminaicanbedetermiiiedbythetermi- credit cards. 

nal vendor as part of its standard product strategy. FIO. 3 Ohatraies the hardware of the ZON terminal 

Various standard modeb having different features can in more detaiL The overall hardware system is gener- 

be offered by osmg somewhat different application aDy quite conventional and the details of iu components 

progiaint for ttecfifferent features of the different mod- 65 and the functioning of each wiU be apparent to persons 

eb. The terminal can also be nwtn»iiie< l in its function knowledgeable about local terminal hardware. Thus 

by provkling a custom applicatioa program which adds these details will not be set forth herein, and only those 

other features to the standard ones provided or alters aspects of the hardware which are pertinent to the 
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Central processor unit (CP.U.) 40 n^mtni^M i. The Core Programming Methodology 

over addrns^ data awl cQotrol bosses 41 iiia^^^ The method of this invciition includes three initial 
memory 42 and random access memory 43. Read only 5 jj^pj which form the core methodology of the invcn- 

mcm<yy 43 yrestlK operating system program which ^ ^ which are the basis for achieving the advao- 

provides basic functional control of the microcomputer tages d the invention which are sommarized above, 

system within the local terminaL In die ZON terminal^ These three stepa comprise the following: 

a standard Z-80 central pnscesmnmt is en^loyed and (4) Establishing a set of general purpose operation 

the operating system is a version of a real*tmie, mnl- routines to be executed by the local computer system in 

titasking eiecntive called the AMX system available the local terminal with each of these routines compris- 

from KAOAK Products Ltd, of Vanctmvcr, Britiah ing a set of instructions for execution by the central 

Ccdnmbia, Canada. This inventioa is not limited in any processed' imtt in the local terminal in a prearranged 

sense to this hardware or operating system environfflent mtm^ to a cc o m ply fh a specific ^ 
and. as wiQ be an»rent to pmons of sldD hi the com- " (b) Defining a set of commands, each of which is 

method of this mvendon may be used m aasoctated with a q>edfic one of the general purpose 

local I n i ii i i ia h which utilize a variety of computer o p er a t i ng routines iacludf^ at least an operation 

hardware systems and realtime operating systems there* code relating the «>*nm aM to the associated general 

' jf. purpose operation routinep with each of the commands 

Read only memory 43 also stores the tenninal soft- ^ having u ft tm ria t^Ml g^mm* code length substan- 

ware which pci fonns certain of the stepa of the method tially less than the code length of the associated general 

of this mvention which are carried out in the local ter- purpose opemtira routine; and 

minaU m c ludin g the sc hedul e r routhw; the command (c) Storing the set of general purpose operation rou- 

execntioo ronthw and the ap pli ca tion program down- tines m the read only memory of the local terminaL 
load routine. ROM 42 stores the oeneral purpose opera- 

tion routines which ar« accessed by the application a. Estabhshmg the General Purpose Operation Routines 

program modules of the applicatioo program. Read The step of estaUtshing a set of general purpose oper- 

only memory 43 may store certain predefined ROM- ation routines involves identifying all of the specific 

resident piogiam mo du lea which are standard program tasks which the local computer syartem in the local ter- 

modtiles fbr performing tasks which are typicaDy in- minal may be called upon to peifoim in the particuiar 

cfaided as standard functiou of die local terminaL It type of application to which it wiU be devoted. Once 

may also store a defiutt applicatioo program having diese tasks have been kientified and fully defined, it b a 

fimiled features so that the terminal operating system rdatively straightforward, though not necessarily triv- 

can copy this defruk program to random access mem- 35 iaL task to create the set of routines which will accom- 

ory 43 in the event tittt there n a major p rob l em with plbh these tasks. The routines must include the capabii- 

die Ime gi ity of the appli c ati o n pr o gram stored in ran- ity of performi ng aO tasks which are necessary fbr the 

dom access memory 43. In addittoo ROM ^ may store types of application progrras to be executed by the 

the firflowmg program com ponents; teraunaL 

data entry routinca 4q Pre ferab ly^ the general purpose operation routines 
a control string interpreter will be created in mirhinf language which can be as- 
a ffle man a ger system scmMcd into macfatnr instructions which, in turn, can be 
a direct download program directly executed by the central processcu' unit in the 
** nusoeOancoos support routines. local terminaL This central imccssor unit win typically 
or any other functions which are to be made available 45 be a micropr ocessw having a specific machine instruc* 
under the ccmtrol at the ap pl icati on program. tion set Utilizing ™^^«'*^ language programming and 
Random access me m or y 43 stores the application havmg such p ro gcat us authored by a highly skilled 
p i ogiam modules which are downloaded firem the re- machine i«tigiMgg> programmer wOl |m>vide the tetest 
mote computer ak»g with odier ittfonnatioo forming execntioo time for the indivkltta] general purpose opera- 
Uie ope r atiooal environment of the appfication pro- 50 tion routmes and thus fiuter execution dme for the 
gram. Random access memory 43 also has a section appfication program running at the local terminaL 
whidi serves as scratch pad memory, mcfaidmg mem- It mi^ also be possible to use a higher level lan- 
ory sections which may serve as drtaregistas and buff- guage^ sodi as the FORTH computer language, instead 
era. Oetaib of the types of tttfbrmation stored in random of language instr ucti ons. In such a case the 
access memory 43 win become apparent from a consid- 55 execution of the tnumctiona of the higher levd lan- 
oation of the detailed deacjriptksu below of the informa- guage wffl require the mtervention (tf an interpreter. If 
tio n whi di b downloaded as part of the application this does not result m too great a sacrifice of execution 
ptogxm. speed, tibe higher level langnagr approach may be satis- 
Random access memory 43 b preferably provkied foctory. However, since the method of this invention 
with battery badcup to preserve the contents of the «o mherently involves trading off ^Ked of execution of the 
memory whkh are otherwise vdatile in the event of applicatkm f»ogram for reduced application program 
k»8 of power to the local termittaL Another option b to download time, use of expertly authored machme code 
use non-volatile random access memory circuits and for the general purpose operation routines b highly 
ss snciatcd system components which provide the capa- preferred. 

bility to detect an hnpendhig power fidhne and to copy 65 TaWc I appended bmto sets forth a listing of the 

the contents ofthe volatile p(»tion<tfthe random access functions to be per for med by a set of general purpose 

waaory circuits to a nof»-volatiie component of the operation routines which have been created for the 

circttits before all power to the local terminal b lost. ZON fiunily of terminab described above. The descrip- 
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tkm given in Table I of the functional task to be per- conunand set and remember the task associated with 

fonned by each of the general purpose operation rou- each command. As wiD be discussed in more detail 

tines is sufiRdent for a skilled machine language pro- below, each of the ctmmiand names defined at the 

grammer to author a machine code listing which will source code level preferably converts to an operation 

accomplish that task. Flow charts of illustrative exam- 5 code in binary number form at the object code level 

plea of the general purpose operation routines are in- It is the binary operadoo code at the object code level 

eluded in the drawings and will be dis cu sa ed bdow in of the command which relates the command to the 

c o nuect i mi with the step <^ cgecuting thoae routines in associated gencxal purpose operation routine. The man- 

the local tcnmnal. The illustrative ciamplrn toother ner in which this rdationshtp is established in practice in 

with the descriptions of the specific task to be accom- 10 the ZON terminal application of tha invention will be 

pished by each general purpose operation routine aaso- discussed in detafl bck>w. 

dated with each command Ohntxates this step of estab- The advantage of a greatly reduced download time 

lishittg a set of general operatioo routines sufildently ^ application program which is achieved utilizing 

that skOled iHOgnmmen can readily adapt the method ^ method of this mvention is based on defining each 

of thia invention for estahliahing a set of difTerent roo- 15 command f grh at the object code level, the assod- 

* if required* to be used mother typeset local ter- ated command code length is substantially less than the 



code length of the associated general purpose operation 

KDefimngaSet of Commands routine. Table II appended hereto is a chart which illus- 

trates the substaotiai redocttcm in download code size 

(I) General Aspecta 20 achieved using the method of this invention. 

The stq» of defining a set of commands, each of Table II lists in cohmm one several examples of ZAFD 

whidi is associated with a specific one of the general coaunands fbund in TMt L In column two the size of 

purpose operation routines, win typically be canted out the downloaded ot>ject code for each command is 

by estaUtihtng a high level source code veniott of each given. In column 3, the size of tte object code levd of 

command together with a corresp ondm g object code ^ the machine code routine associated with the command 

version d each coonnand and providing program tools is given. Colnmn four gives an estimate of the mtniiniil 

for converting the high levd source version of each wif^ii^f*^ code size tlmt might be achieved fbr use in case 

commawl to the cowe sp ooding object code version. the entire routine were downloaded in Unary object 

Tins approach to dining commands at source and ^ code. TaUe H illustrates that, in most cases, the ZAPD 

object code levds together with creation of compflmg, object code c on»ff M t^Hl has a code size sidiatantially less 

linking and asteml^gtoob for conversiott firom source than tlw code size of the corresponding operation rou- 

to object versions is wefl known in the art. Specific tine. 

aspects of these tools, which are provided for conver- Table III appended hereto is a chart which shows the 

sion of the source levd co mmawh given in TaMe I into iMjt thti tfrn pf Ti Ptt!^ ^yp^ Mi«ch ft P t^*'^^ *^ 

their comspooding object code, are discu ss e d in more defined commands shown in Table L Table IV is a chart 

detail bdow. which shows a set of thirteen data types which com- 

CZ) Pfderred Command Structure and Syntax prwe afl of Ae different ways that parameter types may 

J ^ ^ sprrifirri As shown in TaUe III eadi of the parame- 

ter types has at least a designated default data type and 

code levd IS as foUows: some of die parameters have alternative data types 

r - . ^ - f^p.^ ^p»^ which may be used to specify that parameter. As shown 

<Pn>} L<^^!^>} <"> in Table m, each of the parameter types of byte con- 
stant, integer constant, string constant, and address 

where PI, P3... Pa are parameters associated with the 43 constant have only a de&ult data type. Each of the 



other parameter types have, in additicm to a default data 
The labd portion is typically utilized only if die par- ^yPf- «^ altemate datt types which may be 

ticttlar application p rogr am module in which the com- utilized to speiify the parameter, 
maad it «*rM**f requires a fbr going to default data type is selected for each of these 

that annand line from another locatioo in the applica^ 30 parameter types wfak± have altemate data types on the 
tioaprogmn module^ The coamiandimme is an integral basis of the data type wfaidi b most Ukdy to be used to 
poftioa of the co mman d, as is a s p ecifi ca rt ott fbr eadi satisfy tiua parameter. As will be discussed below, this 
|i«»« «i ^t*F which is with a ^^^-wiii^t Com- teads to Shorten the overall download code fbr the 

ment statements set off by the semicolon are optionaL applica t ion program. 

Oood programmers provide wdl «*i«m ^ « t^Nj source 33 Table iV, in addition to giving the data type refer- 
code fbr purposes of documenting the overall fu nc ti oo- «nce used in Table m, gives the data type name, the 
alsty of the ap p iicat ioo ptogiam module in which a type of identifying syiabol which b used at the source 
sequence <d r^mtikh is provided. code levd fbr specifying the data type ref er en ce and an 

Refening to Table I it a seen that some commands do ex a mple of a p aramet er s pecific a tio n utilizing the tdcnti- 
aot have any parameters associated with the rmmmA^ 60 fying symbol In addition. Table IV spedlies the length 
while other co i nntamh have one or more wmif**** of the parwnctff in terms of the number of dght bit 
parameters. It is also seen that the name assigned Id each bytes which a parameter utilizing that data type will 
command pr eferab ly is a form oi shorthand lefereuce to occupy in the object code form of the command and the 
the task which the nsociafed general purpose operation number of bytes that will constitute the value of the 
routine performs. Hus shorthand referenc e a ppr oach to 65 parameter daring executkm of the general purpose op- 
assigning command names b not a requirement ci the eration routine associated with the command. The 
inventioa, but b good practice since it greatiy assists the length specified as **n'* means that the length can be up 
programmers utilizing the set of commands to learn the to 233 bytes. 
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As would be expected* eadi of the 1>yte" types of 
data type ref erences wiU takeon a value of a sm^ byte. 
Each of the 'integer" data types win have a valoe speci- 
fied by two bytes and each of the strings wiD have a 
value specified by '^n'* bytes* Lei* up to 225 bytes. The 
c Kten d ed address data type does not take on a value 
since it is typically used to specify a location to which 
theprosram bnoch under certain conditiotis. 

It should be understood that the parameter type sys- 
teoi used in the preferred unpJementation of the niethod 
of this in vention as shown in TABLES m and IV b not 
the only ai^mach that could be impl eme n ted. One 
alternative is CO define each command such that the 
parameters laaocia ted with the command can be satis- 
fied by only one data type. This would permit the com- 
mand parsing module for each conmiand to directly call 
the parsing routines for the parameters associated with 
the command without ming an intennediate parsing 



would eliminate the parsing control routines. Overall it 
would make the programming language much more 
cumbersome to handle. 
It is thus seen that the preferred system of using pa* 
5 rametcr types which include varying parameter types 
which can be satisfiriri with plural data types provides a 
powerftil and elegant way to achieve full programmer 
flexibility in satisfying parameters required by a particu- 
lar operation routine without proliferation of com- 
10 niands. The programmer needs only master the source 
symbol notation for the different data types to use in the 
source syntax of the command and the data types asso- 
ciated viith the different parameter types. In connection 
with this, the information shown in TABLES III and 
IS rv includes a new alternate form of notation which is 
difTerent ton the form used in TABLE I and which 
win eventually make the whole structure of this param- 
eter system mm logical and thus easier to remember. 

contro l r o utin e* It would also eliminate the need for the 
CURVPARM dau structure dement, the VPARM 20 SyntM of D^«d Commands (FIGS, 

array, and the data type data elements in the bitmap/op- 4Aand4B) 
code system for the object code command syntax dts- Referring back to Table L it can be seen that, in this 
cussed bdow. particular implementation of the method of thb mven- 

Howevcr, hnp le mc nt tng this ahemattve approach tion, each of the c ommand s in the defined set of com- 
would require that a much larger number of commawh 25 manda is assigned an opcode group and an opcode num- 
be defined just to handle the different ways that the ber. The opcode group and opcode number set forth in 
parameten ts ao ci a ted with a particular opmtion roo- Table I for each command is given in a decimal nota- 
txnc are s p ecified in the command. For namplr, con- tkm. In the object code command syntax, the opcode 
sider the SEND— CHAR commaitd whidi, as shown in group is represented m biimry form as 2 binary digits 
TABLE I, utilizes two X type parameters m the pre- 30 n>its'*) in a bitmap byte. The opcode number is repre- 



ferred approach to parameter specification. The X type 
parameter is a varymg parameter type with four differ- 
ent data type satbfiers. To cover all <tf the different 
ways to saiisfy two X type parameters with different 
data types with dfficrent could potentially 33 

require sixteen different commands, within a family of 
co mmands that would aD use the same operation roo- 
tine but wouM require different r"*"'*'**T parsing roo- 



seoted in the object code command syntax in the form 
of 7 bits of an opcode byte. Thus, in this version, the 
ope r a t i on code which b deffaied for each command in 
the set of commands a a combination of a binary op- 
code group value, also designated **opset**, and an op- 
code number, designated '*opcode~. 

The purpose fbr this ap proa ch can briefly explained 
as follows. The Z80 micro p roces sor utilized in this 
terminal b an 8 l»t micro processor. Accordingly, the 
Some <rfthe comm a n ds listed m TABLE I use fbur or 40 object code version of an application program module 
five varymg parameter types. Using the alternative is limited to use of 8 bit bytes. An 8 bit byte can take on 
approach of defining commands with only one fixed set 256 different values, but with one bit reserved in this 
of dau types to satisfy the associ a ted parameters could implemetatioa for a byte type flag, only 7 bits are avail- 
drastically proliferate the number of commands which able for designating the opcode. Thus, in order to pro- 
would be needed to provide die programmer with a 43 vide the capability of having more than 128 commands 
reasooaUe levd of flexibifity in satisfying die parame- and mm than 128 associated operation codes, the op- 
tcrsrequiied for a given operaticmroutiBe to perform its code group and opcode number scheme was adopted. A 
task. To make this app roa ch practicable, the command two-bit opeset number provides for four opcode groups 
definition step would necessarily leave out some posai- and a seven-bit opcode number provides for 128 differ- 
biltties, because pr c gramfl sets would not be able to deal 30 ent opcodes in each opcode group. Tog^sther they pro- 
witfa that many diflierent r , omm a nrts and keep them videthecapabilityof having up to 312 total commands 

and a ss o ci a te d operatioo codes. 

FIGS. 4A and 4B ilhmnte the operatioo code system 
whidi has been adopted fbr implementation of thb 
33 inventiott in the ZON terminals. Thb e m bo dim ent of 
the operation code system utilizes a combination of 
opcode bytes and bitmap bytes as shown in FIG. 4A 
Each opcode byte and bitmap byte has a bit 7 represent- 
ing a byte type flag and the value of that type flag disttn- 



sorted out Moreover, the ■M^jiYmm nmiber of 
niands which could be specified by a single byte operar 
tion code would be rapidly riceedrd, making sixteen- 
bit o pe r a tio n codes nrcf stary. 

It should be noted that thb aiteniative approach to 
i mplementat ion would not alter the number of opera- 
tioo routines that wouM need to be established, but it 
would multiply the number of general p ur pose opera- 



routines to be established in die sense that each of 60 gubhesopoide bytes from bitmap bytes. If the type flag 



the different c ommands in each family of commands 
would require a different command parsing gw^i^ ^if 
Proliferation of the of commands would greatly 

increase the number of groups of opcodes that would be 
r e quir e d , and thus increase the size of the opset pointer ti5 
table and opcode pointer table to be stored in ROM. It 
would also dramatically increase the number of com- 
mand parsing modules to be stored in ROM, althcmgh it 



has a binary 0 value, the byte b an opcode byte. If the 
type flag Im a binary one value, the byte b a bitmap 
byte. The remaining seven bits of each opcode byte 
represents the binary opcode which can take on one of 
128 different values. 

The low-order six bits of a bitmap byte, Le. bits 0-5, 
represent three groups of **dau type" dau elements. 
Each of these data elements b used for specifying the 
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data type used by the programmer in the source code 
level of the conmuiid to satisfy the parameter. Since 
each parameter type which takes on varying data type 
values has at most four possible data types associated 
with XU two bit data elements are sufficient to spediy 5 
the data type. Table m shows the binary values which 
are used in the dau type data elements of the bitmap 
byte for dnignatiiig the datt type of the paraineter. 

The sixth bit of csch bitmap byte is an opset bh and is 
used to dfsjgnatft the value of one of the two biu nti- 10 
Bzed to specify the opset in which the command associ- 
ated with the particular operation code b grouped. 
Since there is ottfy one opset bit in each bitmap byte; the 
operatioo code for each command may need to utilize 
two bitmap bytes to designate the opset into which the 13 
particular gnmtMMui is gro up ed. It will be seen* how- 
ever* that for commands which are grouped in opset 0» 
one or both of the bitmap bytes may be ^'implied** bytes 
that are not actually present m the object code com- 
mand syntax. For io opset 1, one of the bit- 20 
map bytes may be 'implied". In odwr words» 1 or 2 
bitmap bytes may be irWmtnatrd, depending on the num- 
ber of non-default type varying parameteis whicfa are 
specified by the programmer in using the associated 
command. FIG. 4B iUustrates this operation code Knt- 25 
map and opcode system mote cxtensivefy. 

As shown m FIG. 4B, the object code command 
syntax for a command which fidb into opset 00 may 
have one of three different suu c tui es. AD co mm a nds m 
opset 00 which have no varying type parameters can be 30 
represented in object code syntax by a single opcode 
byte fbOowed by whatever paramrtfr bytes are re- 
quired. In addition, any command in opaet 00 which has 
parameter types which may have varying dau types, 
and for wUdi all of the assigned dau types are the 35 
definih type, may be represented by a single opcode 
byte (bDowed bytes comprising the parameters 
thf miflves. In both of these cases, bo bitmaps are re- 
quired since the opset 00 is the defSuitt opsec As win be 
shown in other Hgures diimiMrti below, the **transla- 40 
tor^ program uses an opset data structure which has a 
dcfinilt value 00. Another way c^looldng at it is that the 
operatioa code for the command cootains two implicit 
or understood bitmap bytes wherein the opset bit in 
each the bitmap bytes, and all of the btimap **data 45 
type" dements have value Qi Since there is no need for 
actual bitmap bytes^ there is no reason for tlw compiler 
which geaenaes the object code versiou of a command 
widi no varying or wm-defimlt parsmeten to include 
any bitmapa. 50 

The second form whicA the object code command 
syntax may take for com i iiaMfa wfaidi are grouped in 
opset 00 c o mbin es a sin^ bitmap byte with a sm^ 
opcode byte followed by whatever par a meter bytes are 
required. A single Iritmap byte |W!i mils up lo three noi^ 35 
defiuilt varying parameters to have their data types 
sp eci fi ed in tfie three data type data dement s wtndi are 
provided m a smgle bitmap byte. The opset bit in the 
single bitmap byte must have a 0 value in this case to 
cor re sp on d to the first bit of the two-te opset specifier. 60 
In this case the operatioa code fin^ the command has one 
bit of the two-bit of&et specifier understood, i.e., one of 
the bitmaps is implied or undentood and not physically 
present. 

The third form of object code command syntax for 65 
commands which fall into opset 00 b shown in FIG. 4B 
as involving two or more bitmap bytes followed by an 
opcode byte and whatever parameter bytes are re- 



quired. With two bitmap bytes -actually present, up to 
six non-default dau types can be specified for parameter 
types which can talce on varying dau types. It is seen 
that the opset bit in each of the bitmaps has a 0 value 
and these two digits together indicate opset 00. 

As shown in FIG. 4B, commands which are sssigned 
to opset 01 may have an object code command syntax in 
one of two different forms. The first form involves a 
single bitmap byte and the second form involves two 
Istmap byteSw In the single bitmap byte case, the opset 
l»t must have a value 1 to designate that the associated 
command has been assigned to opset 01. If two bitmap 
bytes are present, the opset bit in the first must have a 0 
value and the second must have a 1 value so that to- 
gether tiwy designate opset 01. As seen the first form of 
command syntax with a single bitmap byte can handle 
up to three non-default varying parameters and the 
second form can handle up to »x non^default varying 



Two additional opcode groups, namely groups 2 and 
3 having opset values 10 and 11, respectively, are pro- 
vided for in the operation code system utilized in the 
embodiment of this invention implemented in the ZON 
termittal, but none of the defined commands have been 
assiged to either of these opcode groups. Opset 10 and 
opset 11 each have an object code command syntax 
which re quir e s two bitmap bytes to specify the two biu 
which dfsignatf the opset In other words, two bitmap 
bytes must be present regardless of whether the com- 
mand has non^default parameters specified. 

It should be understood that the operation code bit- 
map and opcode system illustrated in FIG . 4B could use 
more bitmap bytes in the command syntax than b 
shown. In the version of the invention implemented in 
the ZON terminal, provision is made for up to four 
bitmap bytes. This provides for up to twelve varying 
type parameters to be included in a command aixi have 
dau types ^>eci fi ed for each. 

To mintmiTr the code size oi the object code form of 
the defined commands, all comnunds whk:h have asso- 
ciated parameters of a type which have only a default 
dau type may be grouped in opset 00 since such com- 
mands will, m every case, require no bitmap byte. Simi- 
larly, all commands which have no associared variables 
may be assigned to opset 00 since no bitmap bytes 
would be necessary for the object code version of such 
conmiands. This approach is obviously not necessary to 
impiementatioQ of the mventioa. 

Another technique which may be used to reduce the 
size of the object code form of the conunands which are 
mcluded in an applicatum program involves rcordermg 
the position oi the parameters, in the ordered list of 
parameters defined as part of the coomiand, as betiveen 
the order designated in the source level, Lc^ the source 
parameter syntax, and the order designatrri in the object 
code, le^ the object syntax. Referring to the command 
set in Table I, it will be noted that in some cases, the 
source syntax and the object soytax of some commands 
having more than one parameter may be different 

Tht purpose fot reordermg the parameters as be- 
tween source and object syntax b to place those param- 
eters which have onfy a default dau type, and/or which 
are most likely to be assigned a default dau type, at the 
end of the ordered list of parameters in the object syn- 
tax. Thb will tend to reduce the number of bitmaps 
present in tlw object code of the applicaticm program 
snce dau type daU elements in bitmap bytes are only 
required to designate non-default dau types for varying 
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panmeten. This is not a requirement of the operation operation code is a sixteen bit code. This sixteen bit 

code bitmap and opcode byte system used to implement code may be utilized to directly address die associated 

the method of this inventton* but it Is rdativeiy easy to general purpose operation routine or a pointer to the 

provide this feature in the compiler which converts the general purpose operation routine, 
source code level of the commands to the object code 5 _ ...» ^ . ^ . 
form thereof, and it provides further compression of the Compdmg Souroe Code Commands mto Object 

size of the object code to be downloaded. Code Command Syntax 

(4) AltemativeOperation Code Systems and Associated <tecription of the operation code 

brtmap and opcode system, persons of skill m the pro- 
vwjcci v^uuuDHM ofutu ^f-iw^ jq gj,m„„„ng ^ fcadfly appreciate that the conversion of 

It should be understood that the method of this invea- the defined commands at the source code level to the 
tioo is not limited to the operation code system de- object code command syntax involves a relatively sim- 
scribed above and other approa ches to defining com> compiltng function. Basically, the compOer converts 

manris which Include an operation code r^attng the the ctmpound name and the assigned parameters into a 
c ""™ ''^ to an a ssocia ted general purpose operatic 15 set of 1 to 5 numeric vahMs re|»vsenting in decimal 
routine could be provided. For ezamplcr consider a case number fbrmat the bmary values of bitmaps and op- 
in which up to 256 commands may be defined and none codes. These decimal numbers are followed by the 
of the c omman ds requires more than four ooo-default actual parameters associated with the command. As 
varying parameters. In such a case^ the operation code shown in the example of the generic tr ansa ct io n tenni- 
system could utilize the object code command syntax 20 nal program in Tables XXX and XXXI the compUer 
shown in FIG. 5 A. converts the source code command syntax into a se- 

In this system* each command at the object code Icvd quence of code statements which can then be operated 
would have a single bitmap byte and a shigle operation on by a machine language assembler and linker program 
code byte fiirflowed by necessary parameter bytes. Since to convert the code statements into binary form for the 
there i s no pr ovision for a type flag m either the bi^ 25 download into the k)cal terminal The final binary ob- 

the ope^on code byte, both bytes mmt ahvays be jcct code form ofthe generic program is shown in Table 
presotjote ot^ code level, so that the two bytes XXXIL The process of conversion ftom source to ob- 
can be dntmgmshed by thcsr pontiott m the multi-byte jcct code wiU be discussed in more detail bdow. 
command sequence. Obviously, the order of the bitmap 

and operatsoo code bytes could be reversed from that 30 c. Sttmng the General Purpose Operation Roudnes 

^^"SlS'iJ^?''^ ^ . ^. ^ ^. (I) The Preferred Storage and Accessing System (FIG, 

FXO. 5B shows another system m which two bitmap 9) 
bytes are present in the object code command syiHax 

along with a sin^ operatioo code byte. The approach FIO. 9 tUnstrates one approach to storing and access- 
shown in FIG. 5B would permit up to eight varying 35 general purpose operation routines based on the 
parameters to be designated with difRerent data types. opset/opoode system for designating the operation code 
Again both bitmaps would always have to be present, ^ ^ asso ci a te d command. As shown in Table I, most 
and the i» af ^' in t«j«i program running in the of the co m ma nd s include a command name which is 

local terminal would ^wtiwgtfnh the bitmap bytes and converted to an operation code and also a set of parame- 
the operatsoo code byte on the basis of positioo in the 40 <ns with one or mm parameter members in the set. 
object code command syntax. Other systems with more Since this implementation of the method of this tnven- 
bitmap bytes to-provkle for more data type ^ tion provides fen* parameters of varying data type, the 
meats (or varying parameters could also be used. general purpose operation routine associated with each 

FIG. 6 iDnstrates another version of an operation command which tnchides parameters which may take 
code system which may be utilized m versions of this 45 on varying dam types must have the capability of first 
invention in which varying type parameters arc ooc **parsing** the parameters associated with the command 
used. In this case, bitmap bytes are not ntitivmA and two s^d then executing an operation routine utilizing the 
operatkm code bytes are provided. The operation code parsed parameters. 

bytes may, for example; tadke on values corresponding to For purposes of conceptual clarity, the general pur- 
ASCII ch ar ac te ia with two c h a ractc n designating a> 50 po«e operatiott routine asso ci a ted with each command 
operation code. This system is actually used in one will be considered to inc or p or ate the parameter parang 
alternative implementation of this invention described roottnes required for paring the parameters associated 
below. It should be apparent that the two opcode bytes with the coonnand. This incMporation may be accom- 
cottkl also designate corre spon ding co mmam fa and re- plished <firectly, ie. by actually including the necessary 
toted operation systems m accordance with other nota- 35 parsing rtMitines with the operation routines. Altema- 
tional approaches. tivdy, aitd preferably to save memory space in the local 

FIG. 7 Olnstrates an operation code system which terndnai, the necessary paTamerer parsing routines are 
migfat be employed in a local terminal system which i n corp or ated by reference to a set of parsing routines 
utilized a central processor unit operating oo the basis of wfaidi are global to and shared by the different opera- 
sixteen bit words, rather than bytes. In such a system, 60 twn routines. The storage and access system shown in 
aght bits ofthe word couU be dnignarrd as the opera- FIG. 9 inustrates an approach to storing parang rou- 
tioo code and the other eight bits drsignated as 2-bit tines separate from operation routines and incorporate 
data elements for varying parameters, In this case the ing parsing routines by ref er en ce into general purpose 
position ofthe bits within a single word designates what opention routines^ 

the bits represent 65 As shown in FIG. 9, one implcmcntadon of the 

FIG. S shows another alternative operation code method of this invention involves storing in the read 
system which might be employed in implementing the only memory of the terminal an opset pointer table, an 
owthod of this invention. In the FIG. S system, die opaxie pointer table, a set of command parang mod- 
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ulcs, B set of paning control roadnes, a set of dau type 
parsing routines, and a set of operation rootittes. The 
opcode pointer table is divided into sq»arate opset ta- 
hles and each opset within the opcode pointer table has 
a pair of pointers assoriatrri with each opcode value. 

Gat pointer is a parsing module pointer and the 
second a an operation rootme pointer. The parsing 
OKMliile pointer containt the address of one of the com* 
maud parsing modnles, Le. the particular command 
parsing module annriaird with the command to which 
this opcode has been assigned. The operation rontiiie 
pmntcr containa the addrcai of the a sso ci a t ed operation 
roatin& Each of the command parsing m odules i n clt id c s 
prograa code for caning in sequence one or more of the 
parwig control routines. E a ch of the parking control 
routines indndes p io giam code for calling one data 
type parsing routine from a subset of the total groiqi of 
data type parsing routines. This will be explained in 
more detail below. 

The opaet pointer table confaim three bytes of infor- 20 
matioa, the first two bytes being an opset pointer and 
the third byte designating the maiimum nnrnhfr of 
opcodes that have actually been defined in that parttco- 
lar opset As will be cfiscusKd below, the MAX.OP- 
CODES byte in the opaet pointer table is used to verify 25 
whet h er the opc od e number in the command being 
eircntrri is a vriid one, that is whether it Ms within the 
range of opcodes actuaOy utilized in the system. The 
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routine by reference into an overall general purpose 
operation routine associated with each command is to 
reduce the amount of memory required for storing gen- 
eral purpose operation routines in the read only mem- 
ory of the local terminal It should be apparent that a 
trivial alternative, albeit one which would consume 
fflhutantiai additional memory space, would be to in- 
clude all of the parsing control routines and data type 
parsing routines reqiurcd for a particular command in 
the actual general purpose operation routine associated 
with that command. FIO. 10 illustrates such a system. 

In this case the opcode pointer table need only con- 
tain a two-byte address ci the corresponding general 
purpose operation routine. It should be apparent that 
this is a much less desirable approach from a memory 
qsace stamlpoint since sonae commands have as many as 
five or six associated parameters and several of those 
parameters may be varying data type parameters. In- 
cluding aO of the parameter parsing routines required in 
such a case locaUy in the general purpose operation 
routine would dramatirally increase the code size of the 
general purpose operation routine and thus substantially 
affect the cost <3i memory in the terminal It should be 
noted that this would have no affect on the application 
pfogiAUi download time and would have little or no 
beneficial affect on the speed of execution of the indi- 
vidual oomrnands of the applkatioD program. 

Going back to FIO. % the reason for separately stor* 
ing conunand parsing modules relates to the circum- 



opset pointer for each of die opset groups contains a 

two-byte address which b the address of the start of the 30 stance that a number of the commands which are de- 
corre sp ond i ng opaet section of the opcode pointer table. fined and set forth in Table I share the same ordered list 
Am shown m FIG. 9, there is an algorithm wfasdi is of parameter types. For example, there are several corn- 
executed 10 locate the a p p ropria te opset pointer in the mands having a single parameter of the same parameter 
opMt pointer table and another algorithm to calmlatc type. There are other commands which have two pa- 
the location of the parsing module pointer. From the 35 rameters of the same types in the sameorder, and there- 
fore have the same object syntax. Thus memory space is 
conserved by having the general purpose operation 
routines share command parsing modules. 

However, as another alternative approach which 
would not consume a large anxyunt of additional mem- 
ory, each of the general purpose operatioo routines 
might inchide its own command parsing module of the 
type r e quir ed for calling the parsing control routines 
which, in turn, caO the ap pr opria te data type parsing 
routines^ This altemadve scheme is shown in FIG. 11. 
In this case the opcode pointer tsbie would contain the 
address of the general purpose operation routmcs and a 
separate parsing module pointer would not be required. 
The rotmnanrt parsing module wouU be located at the 
starting address of the general purpose operation rou- 
tine wteh b pointed to by the operation routine pointer 
in the opctxie pointer taMe. 

Referring back to FIG. 9 in conjunction with Tables 
in and IV, ft should be understood that the number of 
data type parsing routin e s stored in read only memory 
in the local tenmnal corresponds with the number of 
specific data types set forth in Table IV. In other words, 
in the present implementation of thb invention in the 



binary object code vcrsimi of the command, the 
mand nccwtion routine recovers an opaet value and an 
opcode vahse and stores these in data structures as win 
be des cribed below. The locadon of the opset pointer 
may be ca hmlalc d by addmg three times the binary 40 
vahM of OPSET to the starting address of the opset 
table. Since there are three bytes isioctated with each 
opset in the opset postter table, thb algorithm, in effect, 
raimlatn the address of the opset pointer. When the 
opset poi nt er has been retrieved from thb address, the 45 
address of the parsing module pointer b calculated by 
adding to the two-byte address of die opaet pointer a 
vafaie of fbor dmes the opcode vahie rec ov ered from 
the binary version of die command. 

Once the address of the parsing module pointer has 
been cafeolaced, the two byte address which b stored at 
the caJcutated pafsmg module pomter address can be 

V^^*fTfP and used in gati tfw ^aat^mt^iA c€^nmmw%A puffing 

m odul e . The su b seq uent caD to the operation routine 
can be accorapltshcd by ntiliimg the two-byte address 
which comprises the operation routine pointer immedi- 
ately following the parsmg module pointer. It b thus 
seen that the opcode pointer table directly atsoriatn a 

command parsing module with an O| > rr a t ion routine. ZON ternunal, there are thirteen data types and each of 
Together the command parsing module and the roo- 60 these data types has a separate data type parsing routiiM 
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tines which it calls and the operation routine itself COTi- 
pnse the general purpose operation routine for each 



(2) Alternative Storage and Accessing Systems (FIGS. 
10 and 11) 

The purpose for unng the preferred scheme discussed 
above for incorporating a parsing routine and operation 



ffwociated therewith. As shown tn Table HI, there are 
twelve parameter types and each of these parameter 
types has a parang control routine associated therewith. 
Those parameter types whkh have only a default 
65 dau type have a parsing control routines establbhed 
such that it will call only a single data type parsing 
routine, namely the one associated with the single data 
type assigned to that parameter type. Others of the 
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computer system vk siid oommnnimtinn chauiel. 
indwtmg the step of storing for each said set of 
comnuiids said opentxm code assodaied with said 
p r e ar r an ged seqncace oi commands in each of said 
api^icatioa program modules of said preselected 
application pr ogr am in said random access mem- 
ory; and 

fl cstaUisfaing in said local con^mter system a pro- 
gram execntioii routine for enabling said central 
inocessor unit to execute a selected one of said 
ap pHrati c n pr o gram modules in response to said 
input means by rcpetitivdy performing the steps of: 

(1) reading said as so ciated operation code associ- 
ated with said selected application program |^ 
module stored in said random access memory; 

(2) .accessmg a s p ecifi c general purpose operatioa 
routine ■nocirted with said associated operation 
code; and 

(3) nccnftng said specific general purpose c^wra- ^ 
tion routine. 

4. The method of ciatm % wherem said stq> 

a. mdndes the steps of: 
(!) establishing as a first one of said general purpose 
operation rootbies a START PROGRAM rou- ^5 
tine compnsmg machme mstructions for calling 
for execntio o of a lyccfficd apfrficatiOQ program 
modnte; 

(2) and estabiishmg as a second one of said general 
purpose operatm routiiies a WAIT routine 3^ 
compnsmg marhtne iusuuctioas for suspend lug 
execution <3f an applicatioa program module in 
which an operatioa code oorresponding to said 
WATT routine appears; 
step d. comprises establishing a plurality of api^ica- 33 
tioa program modules each comprising a sequence 
of said operation code, at least a first one of said 
^)p]icatioo pjogiam modules indodtng an opera- 
don code a ss o ci a te d with said START mCV 
CRAM rotttme for calfing for exectttioa of aspect- 40 
fied second one of said ap p li c at ioo p ro gram mod- 
ules^ and at least one of said first and second 
cation p ro g r am m o du ks inrJnding an operation 
code associ ated with said WATT rontiiie; 
said method further oomprisnig the stqM of: 43 
g. defining a program data stnictnre format com- 
^ising a phxrslity of data elements associated 
with eae cut ion of an ai^rficatiaa piugiam mod- 
ule by said prognun esecution routine; 

array storage area for storing a program data 
yoctnre array compr i sin g a plurality of appBca- 
tion program module slots eadi having said pro- 
gram data structure format; 

L establishing in said random access memory an 
area for storing scheduler data pr o gram struc- 
tures coaq»risiiig a WATT data dement for stor- 
ing define 'Vaif* or **ootttinne'* data values. simI 
a frfurality of ACTIVE PROGRAM data de- 
ments each assoctaled directly with one of said 
program dots in said program data structure 
array and sttving one ci two defined data values 
indicatittg whether or not said associated pro- 
gram slot contains data dements asiociated with ^ 
an active apfrficatkm program module; 

j* establishing in said local computer system a |ffo- 
gram scheduling routine for enabling said central 



processor unit to carry out the step of scheduling 
the imgnential cMCUtion <^ application i»ogram 
modules one at a time based <m the dau values 
stOTed in said ACTIVE PROGRAM dau de- 
meius, said execution <tf each active ai^cation 
pro g r am module continuing until said WAIT 
data dement contains a watt data value or until 
die currently executing ^yplication program 
module has completed its executicm; 
said START PROGRAM routme in dudin g instruc- 
ticms for loading one of said ACTIVE PRO- 
GRAM data dements with a data value indicating 
pr e sen ce of an active application ptr o giam module 
and for loading into said array storage are of said 
r a n d om acc es s memo ry a ccOTespondmg program 
data structure associated with said application pro- 
gram module called for execution by said routine; 
and 

said WATT operation routine induding instructions 
for storing said ''wait^ data vdue in said wait data 
etement of said sdicdnler data structure. 
9. The method otdaim 4^ wherein said program data 
structure amy establtsbed m step h. is a fixed array with 
a fixed n unrtw of ^»plication j»ogram module slot^ 
said ACTIVE PROGRAM daU elements in said 
scheduler data s tructure H^Twf in step L com- 
prise an ACTIVE PROGRAM fixed bitmap data 
structure with each bit location in said bitmap cor- 
re^ondtng to as associated applicatioo program 
itio d ul e slot in said program data structure array 
and storing one of a first bit vdue or a second bit 
value inriioatmg the presence or absencev re^ec- 
tivdy» of an active qi|rfication program module in 
the associated apportion program module slot; 
said START PROGRAM routine indudes a parame- 
ter ^ediyittg whscfa application progrsm module 
slot should be utilized for storing dau suucuu e s 
for exe cut ion of said asso ciated ap^ication prc^ 
gram module. 

6, The method of daim 5» ^nterein said wait dau 
dement established in step i may also store a defined 
''HALT" <bu vahie; said step a. Inrtlwr ifKOndes the 
step oft 

(3) estabyshing as another one of said generd purpose 
operation routines a DONE roatine c ompr i sin g 
instmctiotts for loaiSng said wait dau dement with 
a HA LTda U value and loacfing the bit location in 
the ACTIVE mOGRAM bitmap of the applka- 
tioo peogram module which inchides said DONE 
routine with said second bit value indicating the 
absence of an active api^ication program module m 
the asso ciated 49>plication program module slot; 
and each of said application pr o gram modules which 
completes execution without Inanching to another ap- 
pKration program module includes an operation code 
corresponding to said DONE routine as a last command 
thereuL 

7. The method of daim 6, wherein 

said s chedul er dau structure established in step i. 
forther comprises a BACKGROUND Intmap hav- 
ing bit locations cor r e sp onding to application pro- 
gram module slots in uid program dau structure 
amy estaUished in step h. and storing one <^ first 
or second fait vdoes indicating whether the active 
application grog ram m odule m a corresponding bit 
location in the ACTIVE PROGRAM bitmap has a 
badcground or foreground attribute; 
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paraineter types hive three or four possible data types The step of establishing an application program mod- 
associated therewith. Accordingly the parsing control ale is carried out by a programmer^ utilizing the defined 
routines asso ci a ted with those parameter types are es- command set to put together a meaningful ordered 
tablished to determine the actual dau type and call one sequence of commands, including designated paramc- 
ofthreeorfourofthedautype^i3ingrou^ 3 ten for each of the commands, so that a meaningful 
S2t2l;^S^;SJS^ ^isdefincdbythea^^^^ 
v^V^^^^^S one; thiSoTSlau type ^ estabhshmg an overaU application 

parsing loutines. program include establishing the environment of the 

The number of rnminMrt parsing modules cone- 10 overall application program, such as establishing appii- 
sponds to the total number of different ordered lists of cation program variables and files which will be ud- 
parameten in the object code syntax for the totality of Itzed. All of these are relatively standard aspects of 
the commands which ace defined relative to the general ^ogramming. A specific illiistrative example of steps 
purpose operatton roatittes which are established. Al- hivolved in establishing an overall application program, 
though thb means that there are large number of com- 15 utilizing the specific implementation of thb invention 
mand parsing modules, the amount of code required to whidi has been created for the above mentioned ZON 
execute a sequence of calls to different parsing control terminals, and utilizing the conunand set which is illus- 
■ootines is relatively smal^^ ^ Table I, wiU be set forth in detail below, 

memory space occupied by the large number of com^* 

mand parsing modules is not overly extensive. 20 3. Communicating the Application Program Module to 

Referring back to FIGS. 5-7 which depict alternative the Local Tenninal 

operation code systems, if a smgle 8 bit operation code _ . . 

ittshown in thoe alternative examplesb utilized, a The nwt step of the general method of this mvcntion 
sin^ opcode pointer table b aD that is required. The » » communicate the application program module 
parsing module pointer location can be rslr w li tfil by 23 which has been created firom the remote computer to 
■HHttig four >im*>jt the values of the operation code to the local tcrminaL This communication step, referred to 
the startmg address of the opcode pointer table: general as downloading the application program, in- 

Rcfening to the operatimi code systein shown in volvcs the use of a download program routine operating 
FIO. 8, the sixteen bit operation code could be used to et the local terminal, a download program operating at 
directly address the parsing modu l e pointer in a single 30 ^^n^ remote computer a communication link be- 
opcode pointer table. If the operation code system de- tween the remote computer and the local terminaL In 
pa^edm FIG. 8 were tti^nd inra^jmicti^ with the general diis communicating step or downloading step 
approaai to stonng the general porpOM operatton roo- involves communicating a copy of the binary object 

m*»A r,.n_>nii nji^r^t\n.Mi w^Jiti^ »k« fflg all of the uidividual appbcadon program modules 

uea general purpose operanon routine ana ue opcooe ...... - ^ ^ ^ • ^ 

pointer table could be estalAshed m the pnor step of the method, mto the 

These variatiaBS in implemeiitatioo of the three mitiai random access memory of the local terminaL It may 
steps which form the core methodology of dtb inven- ^ invcrive communicating ASCII data, die meaning 
tioo illustrates that the mr^h pd of this invention is a 40 and usage of which is defined by the applkation pro- 
general one. The invention b not limited to any paiticu- gram, into the random access memory of the terminaL 
lar form of hnpiementttion of the core programming There are numerous ways that this step can be ac- 
methodokyea, which provide a snhtlanri al reduction in complished, and a specific discussion of the application 
the code size of an y pltcation program to b e down - p rogram downloading methodology which has been 
from a remote amtpvaer mto a local tommal 43 implemented ft>r use m the ZON terminal is given be- 
where It wiH be executed. The degree of applicatioii |^ 

SSX^S^^^n'^^S^'^^ 4.'Establishmg a Program Execution Routine 

grce or reonctioo m application program code down- . . .^^t^wi rs*uu i^^m^tir>m 

Ioadtimewill,ofcouise,besoniewha»dependentonthe . The ni^^ m die general method of this mvcntton 
p,^»4oMi»> inniir.ii_iif ^^v^fiffi 30 ' ^ cstabWi m the local computer system a program 

execution routine for enabling the central processor unit 
2* Fnahlrth k^ an Apptication Program Modu l e {q local terminal to execute the applicatiott program 
Having cstaMtshed and stored the general pur pose module. This executioa of the application 'program 
operatioo routines so that they can be executed at the module is accomphthrd by repetitively perfomung the 
local terminal and having defined a set of commanris 33 stepsof reading one of the operation codes stored in the 
rdated to those general purpose ope rat io o routines, the random access me mory at the local terminal, acces sin g 
next step tt to estaMish an application proflyam module aspedficoneof the goieral purpose operation routines 
^V?°**^*^P^'^^'*^^^"P'^^^*^ asK)ciated with the operation code which has been read, 

module win comprise a prearranged sequence of the and then executing the accessed general purpose opera- 
commands which have been defined and will thus direct €0 ^ Am Mm^'^.mm^ m^JZ fUm iJLJLi 
the local tenninal to carry out a sequence of tasks by ^'ST^ ^^^H^^ 
executmg the associated general purpose operation rott- operation routme may mdude parsmg routmes for pars- 
tmesm a panicuhir order. Typically WeraUapp^ ^ ^ ^'•'^ « '"^"^ along with the 
tioa program to run on the local terminal will comprise <H>otion code m each c omm a n d. To illustrate this step 
a number of different application program modules, 65 of the method, a specific example of methodology uti- 
each of which enables the local terminal to cany out a ^htd to execute a general purpose operation routine 
set of functions associated with the transactions or other associated with one command of an application pro- 
operational features which are desired. gram module will be discussed. 



